|
From: Ross B. <ro...@bi...> - 2009-03-05 18:46:09
|
When I run a test program with leak-check, the first error is ==14820== Use of uninitialised value of size 4 ==14820== at 0x40F6841: (within /usr/lib/libstdc++.so.6.0.10) ==14820== by 0x40FE394: std::ostreambuf_iterator<char, std::char_traits<char> > std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::_M_insert_int<unsigned long>(std::ostreambuf_iterator<char, std::char_tra\ its<char> >, std::ios_base&, char, unsigned long) const (in /usr/lib/libstdc++.so.6.0.10) ==14820== by 0x40FE60C: std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::do_put(std::ostreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, char, unsigned long) const (in /usr/lib/libstdc++\ .so.6.0.10) ==14820== by 0x410FEFF: std::ostream& std::ostream::_M_insert<unsigned long>(unsigned long) (in /usr/lib/libstdc++.so.6.0.10) ==14820== by 0x4110073: std::ostream::operator<<(unsigned) (in /usr/lib/libstdc++.so.6.0.10) ==14820== by 0x806903B: boost::test_tools::tt_detail::print_log_value<unsigned>::operator()(std::ostream&, unsigned const&) (test_tools.hpp:299) ==14820== by 0x806905E: std::ostream& boost::test_tools::tt_detail::operator<< <unsigned>(std::ostream&, boost::test_tools::tt_detail::print_helper_t<unsigned> const&) (test_tools.hpp:405) ==14820== by 0x8069085: boost::basic_wrap_stringstream<char>& boost::operator<< <char, boost::test_tools::tt_detail::print_helper_t<unsigned> >(boost::basic_wrap_stringstream<char>&, boost::test_tools::tt_detail::print_helper_t<uns\ igned> const&) (wrap_stringstream.hpp:66) ==14820== by 0x8069EE8: void boost::test_tools::tt_detail::check_frwd<boost::test_tools::tt_detail::equal_impl_frwd, unsigned, unsigned>(boost::test_tools::tt_detail::equal_impl_frwd, boost::basic_wrap_stringstream<char>&, boost::u\ nit_test::basic_cstring<char const>, unsigned, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned const&, char const*, unsigned const&, char const) (test_tools.hpp:461) ==14820== by 0x810E4DA: data::test_method() (Data_test.cc:133) ==14820== by 0x810EE7B: _ZL12data_invokerv (Data_test.cc:40) ==14820== by 0x807BC1A: boost::unit_test::ut_detail::unused boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (*)()>(void (*)()&) (callback.hpp:56) ==14820== by 0x807BC44: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (callback.hpp:89) ==14820== by 0x406765C: (within /usr/lib/libboost_unit_test_framework-gcc42-1_34_1.so.1.34.1) ==14820== by 0x40561B4: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&, bool, int) (in /usr/lib/libboost_unit_test_framework-gcc42-1_34_1.so.1.34.1) ==14820== by 0x4056545: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&, bool, int) (in /usr/lib/libboost_unit_test_framework-gcc42-1_34_1.so.1.34.1) ==14820== by 0x40677B8: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (in /usr/lib/libboost_unit_test_framework-gcc42-1_34_1.so.1.34.1) ==14820== by 0x405AC3E: boost::unit_test::framework_impl::visit(boost::unit_test::test_case const&) (in /usr/lib/libboost_unit_test_framework-gcc42-1_34_1.so.1.34.1) ==14820== by 0x406DE66: boost::unit_test::traverse_test_tree(boost::unit_test::test_case const&, boost::unit_test::test_tree_visitor&) (in /usr/lib/libboost_unit_test_framework-gcc42-1_34_1.so.1.34.1) ==14820== by 0x406E63F: boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&) (in /usr/lib/libboost_unit_test_framework-gcc42-1_34_1.so.1.34.1) ==14820== ==14820== Conditional jump or move depends on uninitialised value(s) ==14820== at 0x40F684A: (within /usr/lib/libstdc++.so.6.0.10) Data_test.cc excerpt BOOST_CHECK_EQUAL(pdi4->next(), true); Data::TIObs p4b = pdi4->begin(); //p4b = 2u; Data::TIObs p4bt = 0u; BOOST_CHECK_EQUAL(p4b, p4bt); // line 133 triggering error First question: why isn't it telling me where the uninitialised value is? Or is it? My understanding is that the first at (0x40F6841) is the instruction location, not the memory being referenced. It may be relevant that I invoked with valgrind --leak-check=yes --num-callers=20 ./test1 --report_level=detailed /home/ross/peter/R/mspath/src/test/inputs Does --num-callers disable other information? I couldn't find a switch that would enable reporting of the offending memory location. Second question: why is the error reported in the equality test, and not at Data::TIObs p4b = pdi4->begin(); ? By uncommenting p4b = 2u I was able to suppress the error, which seems to indicate that p4b is the culprit. Data:TIObs is type size_t. The program is compiled with g++ 4.3.2 with -O0 -g, valgrind 3.3.1 on Debian GNU/Linux Lenny with 32 bit AMD Athlon chip. |
|
From: tom f. <tf...@al...> - 2009-03-05 19:11:30
|
Ross Boylan <ro...@bi...> writes: > When I run a test program with leak-check, the first error is > ==14820== Use of uninitialised value of size 4 > ==14820== at 0x40F6841: (within /usr/lib/libstdc++.so.6.0.10) > ==14820== by 0x40FE394: std::ostreambuf_iterator<char, std::char_traits<ch > ar> > std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char > > > >::_M_insert_int<unsigned long>(std::ostreambuf_iterator<char, std::char_ > tra\ > its<char> >, std::ios_base&, char, unsigned long) const (in /usr/lib/libstdc+ > +.so.6.0.10) [snip] > ==14820== Conditional jump or move depends on uninitialised value(s) > ==14820== at 0x40F684A: (within /usr/lib/libstdc++.so.6.0.10) [snip] > First question: why isn't it telling me where the uninitialised value is? Or > is it? The unitialized value is being utilized in libstdc++; looks like it didn't have debugging information for it, but other places in the stack it does... maybe the debug information in your libstdc++ is incomplete? > The program is compiled with g++ 4.3.2 with -O0 -g, valgrind 3.3.1 on Debian > GNU/Linux Lenny with 32 bit AMD Athlon chip. You'll likely find the report to be much more useful if you upgrade to 3.4.1 and use the --track-origins flag. -tom |
|
From: Ross B. <ro...@bi...> - 2009-03-05 20:03:03
|
On Thu, 2009-03-05 at 12:08 -0700, tom fogal wrote: > Ross Boylan <ro...@bi...> writes: > > When I run a test program with leak-check, the first error is > > ==14820== Use of uninitialised value of size 4 > > ==14820== at 0x40F6841: (within /usr/lib/libstdc++.so.6.0.10) > > ==14820== by 0x40FE394: std::ostreambuf_iterator<char, std::char_traits<ch > > ar> > std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char > > > > >::_M_insert_int<unsigned long>(std::ostreambuf_iterator<char, std::char_ > > tra\ > > its<char> >, std::ios_base&, char, unsigned long) const (in /usr/lib/libstdc+ > > +.so.6.0.10) > [snip] > > ==14820== Conditional jump or move depends on uninitialised value(s) > > ==14820== at 0x40F684A: (within /usr/lib/libstdc++.so.6.0.10) > [snip] > > First question: why isn't it telling me where the uninitialised value is? Or > > is it? > > The unitialized value is being utilized in libstdc++; looks like it > didn't have debugging information for it, but other places in the > stack it does... maybe the debug information in your libstdc++ is > incomplete? I didn't have the debugging symbols installed. Shouldn't it be able to give me the memory address of the unitialized memory anyway? > > > The program is compiled with g++ 4.3.2 with -O0 -g, valgrind 3.3.1 on Debian > > GNU/Linux Lenny with 32 bit AMD Athlon chip. > > You'll likely find the report to be much more useful if you upgrade to > 3.4.1 and use the --track-origins flag. I'm trying to stick with the standard Debian distribution, but I might give that a try. Thanks. Ross P.S. for others: don't forget I had a 2nd question about an apparently late notification of an uninitialized value. |
|
From: Nicholas N. <n.n...@gm...> - 2009-03-05 21:38:16
|
On Fri, Mar 6, 2009 at 5:45 AM, Ross Boylan <ro...@bi...> wrote: > When I run a test program with leak-check, the first error is > ==14820== Use of uninitialised value of size 4 > ==14820== at 0x40F6841: (within /usr/lib/libstdc++.so.6.0.10) > > Data_test.cc excerpt > BOOST_CHECK_EQUAL(pdi4->next(), true); > Data::TIObs p4b = pdi4->begin(); > //p4b = 2u; > Data::TIObs p4bt = 0u; > BOOST_CHECK_EQUAL(p4b, p4bt); // line 133 triggering error > > First question: why isn't it telling me where the uninitialised value is? Or is it? Because when this happens the value is in a register. It's hard for Memcheck to know which memory location it came from; indeed, the value may be the result of operations combining multiple originally-in-memory values. > My understanding is that > the first at (0x40F6841) is the instruction location, not the memory being referenced. That's correct. > It may be relevant that I invoked with > valgrind --leak-check=yes --num-callers=20 ./test1 --report_level=detailed /home/ross/peter/R/mspath/src/test/inputs > Does --num-callers disable other information? I couldn't find a switch that would enable reporting of the offending memory location. --num-callers doesn't disable anything. Upgrade to 3.4.1 and use --track-origins=yes if you want more information, as Tom suggested. One thing the message doesn't say which it could is that the likely use of the undefined value is as a pointer in a load or store. (It could also be as the shift amount in a shift operation, or one or two other obscure cases, but they're unlikely.) > Second question: why is the error reported in the equality test, and not at > Data::TIObs p4b = pdi4->begin(); > ? By uncommenting p4b = 2u I was able to suppress the error, which seems to indicate that p4b is the culprit. > Data:TIObs is type size_t. Memcheck doesn't complain about all uses of uninitialised values, only ones that it thinks are dangerous. See the manual for more: http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.uninitvals And this FAQ as a follow-up: http://www.valgrind.org/docs/manual/faq.html#faq.undeferrors And this blog post if you want a more detailed discussion: http://blog.mozilla.com/nnethercote/2009/02/27/eliminating-undefined-values-with-valgrind-the-easy-way/ And this paper if you really want all the details: http://www.valgrind.org/docs/memcheck2005.pdf Hope this helps. Nick |