|
From: Ross B. <ro...@bi...> - 2009-02-06 18:34:36
|
When I run my program under valgrind the first reported error is an invalid read. However, there is no indication of why it is invalid. The same code has worked OK under 32 bit linux (AMD Athlon) and OS-X (64 bit powerPC, though OS may have been mostly 32 bit). I am now running under 64 bit Xeon. Under gdb, the memory looks OK. First, could this be an alignment issue? That is, can valgrind detect such problems, is the error report consistent with such a problem, and could it actually be a problem. The web seems to indicate that alignment is a performance issue only, but I'm not sure I've found the right docs. Second, could this be some kind of race problem? I notice the multi-threaded boost code is running the tests. Third, any other clues about what this might be, or what it definitely isn't, or what to do would be great. I am assuming it is not an "accessing memory already freed" problem, because the report does not say that. The program was compiled -O0 -d, and is mostly in C++. Here are the first couple of errors; there were lots more. The early errors appear not to be fatal, though a later one is. t$ valgrind --leak-check=yes ./test1 --report_level=detailed /home/ross/mspath/src/test/inputs ==27712== Memcheck, a memory error detector. ==27712== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==27712== Using LibVEX rev 1658, a library for dynamic binary translation. ==27712== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==27712== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework. ==27712== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==27712== For more details, rerun with: -v ==27712== Running 81 test cases... ==27712== Invalid read of size 8 ==27712== at 0x40904A: std::valarray<int>::size() const (valarray:772) ==27712== by 0x409064: mspath::Data::nObs() const (mspath.web:6990) ==27712== by 0x408B03: mspath::DataIterator::advanceToNext(unsigned long) (mspath.web:9353) ==27712== by 0x408C32: mspath::DataIterator::next() (mspath.web:9345) ==27712== by 0x496946: data() (Data_test.cc:129) ==27712== by 0x43903E: boost::unit_test::ut_detail::unused boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (*)()>(void (*)()&) (callback.hpp:56) ==27712== by 0x439062: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (callback.hpp:89) ==27712== by 0x4B40FE0: boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::(anonymous namespace)::zero_return_wrapper>::invoke() (in /usr/lib/libboost_unit_test_framework-gcc-mt-1_33_1.so.1.33.1) ==27712== by 0x4B3343C: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&, bool, int) (in /usr/lib/libboost_unit_test_framework-gcc-mt-1_33_1.so.1.33.1) ==27712== by 0x4B3353F: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&, bool, int) (in /usr/lib/libboost_unit_test_framework-gcc-mt-1_33_1.so.1.33.1) ==27712== by 0x4B40DB1: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (in /usr/lib/libboost_unit_test_framework-gcc-mt-1_33_1.so.1.33.1) ==27712== by 0x4B360C9: boost::unit_test::framework_impl::visit(boost::unit_test::test_case const&) (in /usr/lib/libboost_unit_test_framework-gcc-mt-1_33_1.so.1.33.1) ==27712== Address 0x5588760 is 0 bytes inside a block of size 104 free'd ==27712== at 0x4A1B17F: operator delete(void*) (vg_replace_malloc.c:244) ==27712== by 0x4968F1: data() (Data_test.cc:123) ==27712== by 0x43903E: boost::unit_test::ut_detail::unused boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (*)()>(void (*)()&) (callback.hpp:56) ==27712== by 0x439062: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (callback.hpp:89) ==27712== by 0x4B40FE0: boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::(anonymous namespace)::zero_return_wrapper>::invoke() (in /usr/lib/libboost_unit_test_framework-gcc-mt-1_33_1.so.1.33.1) ==27712== by 0x4B3343C: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&, bool, int) (in /usr/lib/libboost_unit_test_framework-gcc-mt-1_33_1.so.1.33.1) ==27712== by 0x4B3353F: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&, bool, int) (in /usr/lib/libboost_unit_test_framework-gcc-mt-1_33_1.so.1.33.1) ==27712== by 0x4B40DB1: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (in /usr/lib/libboost_unit_test_framework-gcc-mt-1_33_1.so.1.33.1) ==27712== by 0x4B360C9: boost::unit_test::framework_impl::visit(boost::unit_test::test_case const&) (in /usr/lib/libboost_unit_test_framework-gcc-mt-1_33_1.so.1.33.1) ==27712== by 0x4B47F1A: boost::unit_test::traverse_test_tree(boost::unit_test::test_suite const&, boost::unit_test::test_tree_visitor&) (in /usr/lib/libboost_unit_test_framework-gcc-mt-1_33_1.so.1.33.1) ==27712== by 0x4B352D7: boost::unit_test::framework::run(unsigned long, bool) (in /usr/lib/libboost_unit_test_framework-gcc-mt-1_33_1.so.1.33.1) ==27712== by 0x4B40B34: main (in /usr/lib/libboost_unit_test_framework-gcc-mt-1_33_1.so.1.33.1) /home/ross/mspath/src/test/Data_test.cc(129): error in "data": check pdi4->next() == true failed [0 != 1] ==27712== The fatal error: *** glibc detected *** corrupted double-linked list: 0x00000000005fd2a0 *** Program received signal SIGABRT, Aborted. 0x00002affd559207b in *__GI_raise () from /usr/lib/debug/libc.so.6 Current language: auto; currently c (gdb) where #0 0x00002affd559207b in *__GI_raise () from /usr/lib/debug/libc.so.6 #1 0x00002affd559384e in *__GI_abort () from /usr/lib/debug/libc.so.6 #2 0x00002affd55c85f9 in __libc_message () from /usr/lib/debug/libc.so.6 #3 0x00002affd55cd9cc in malloc_consolidate () from /usr/lib/debug/libc.so.6 #4 0x00002affd55cf789 in _int_malloc () from /usr/lib/debug/libc.so.6 #5 0x00002affd55d116d in *__GI___libc_malloc () from /usr/lib/debug/libc.so.6 #6 0x00002affd518f93d in operator new () from /usr/lib/libstdc++.so.6 #7 0x00002affd516e5d1 in std::string::_Rep::_S_create () from /usr/lib/libstdc++.so.6 #8 0x00002affd516ef8b in std::string::_Rep::_M_clone () from /usr/lib/libstdc++.so.6 #9 0x00002affd516f895 in std::string::reserve () from /usr/lib/libstdc ++.so.6 #10 0x00002affd51690a5 in std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::overflow () from /usr/lib/libstdc++.so.6 #11 0x00002affd516da8d in std::basic_streambuf<char, std::char_traits<char> >::xsputn () from /usr/lib/libstdc++.so.6 #12 0x00002affd5163512 in std::operator<< <std::char_traits<char> > () from /usr/lib/libstdc++.so.6 #13 0x00002affd4fbb175 in boost::unit_test::results_collector_t::test_unit_finish () from /usr/lib/libboost_unit_test_framework-gcc-mt-1_33_1.so.1.33.1 #14 0x00002affd4fb8180 in boost::unit_test::framework_impl::visit () from /usr/lib/libboost_unit_test_framework-gcc-mt-1_33_1.so.1.33.1 #15 0x00002affd4fc9f1b in boost::unit_test::traverse_test_tree () from /usr/lib/libboost_unit_test_framework-gcc-mt-1_33_1.so.1.33.1 #16 0x00002affd4fb72d8 in boost::unit_test::framework::run () from /usr/lib/libboost_unit_test_framework-gcc-mt-1_33_1.so.1.33.1 #17 0x00002affd4fc2b35 in main () from /usr/lib/libboost_unit_test_framework-gcc-mt-1_33_1.so.1.33.1 #18 0x00002affd557f4ca in __libc_start_main () from /usr/lib/debug/libc.so.6 #19 0x000000000040420a in _start () at ../sysdeps/x86_64/elf/start.S:113 -- Ross Boylan wk: (415) 514-8146 185 Berry St #5700 ro...@bi... Dept of Epidemiology and Biostatistics fax: (415) 514-8150 University of California, San Francisco San Francisco, CA 94107-1739 hm: (415) 550-1062 |
|
From: Julian S. <js...@ac...> - 2009-02-06 18:47:03
|
> invalid read. However, there is no indication of why it is invalid. Um, it says it is invalid because you are reading freed memory: > ==27712== Invalid read of size 8 > ==27712== at 0x40904A: std::valarray<int>::size() const > (valarray:772) [...] > ==27712== Address 0x5588760 is 0 bytes inside a block of size 104 > free'd > ==27712== at 0x4A1B17F: operator delete(void*) > (vg_replace_malloc.c:244) > ==27712== by 0x4968F1: data() (Data_test.cc:123) > ==27712== by 0x43903E: boost::unit_test::ut_detail::unused > boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>:: >invoke<void (*)()>(void (*)()&) (callback.hpp:56) [...] J |
|
From: Ross B. <ro...@bi...> - 2009-02-06 18:53:57
|
On Fri, 2009-02-06 at 19:47 +0100, Julian Seward wrote: > > invalid read. However, there is no indication of why it is invalid. > > Um, it says it is invalid because you are reading freed memory: I believe those are 2 separate error reports. The addresses are different, and the indentation seems to indicate they are distinct items. Am I misreading? > > > ==27712== Invalid read of size 8 > > ==27712== at 0x40904A: std::valarray<int>::size() const > > (valarray:772) > [...] > > ==27712== Address 0x5588760 is 0 bytes inside a block of size 104 > > free'd > > ==27712== at 0x4A1B17F: operator delete(void*) > > (vg_replace_malloc.c:244) > > ==27712== by 0x4968F1: data() (Data_test.cc:123) > > ==27712== by 0x43903E: boost::unit_test::ut_detail::unused > > boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>:: > >invoke<void (*)()>(void (*)()&) (callback.hpp:56) > [...] > > J -- Ross Boylan wk: (415) 514-8146 185 Berry St #5700 ro...@bi... Dept of Epidemiology and Biostatistics fax: (415) 514-8150 University of California, San Francisco San Francisco, CA 94107-1739 hm: (415) 550-1062 |
|
From: Julian S. <js...@ac...> - 2009-02-06 19:08:09
|
On Friday 06 February 2009, Ross Boylan wrote: > On Fri, 2009-02-06 at 19:47 +0100, Julian Seward wrote: > > > invalid read. However, there is no indication of why it is invalid. > > > > Um, it says it is invalid because you are reading freed memory: > > I believe those are 2 separate error reports. The addresses are > different, and the indentation seems to indicate they are distinct > items. What you have here is one single error report, with two stacks. It's unfortunate that Valgrind's text output is sometimes so verbose, so it's hard to see the boundaries of each error. Errors are separated by a line containing only "==PID==" and nothing else, and you'll find there are no such in what you pasted in. I was just thinking, it is unfortunate these errors are so verbose. One solution is to use the Valkyrie GUI to display the errors (available at http://valgrind.org/downloads). This makes it much easier to see where the error boundaries are, and also much easier to navigate the Memcheck output for large programs. J |
|
From: Michael P. <md...@tr...> - 2009-02-06 19:01:20
|
Ross Boylan writes: > ==27712== > Running 81 test cases... > ==27712== Invalid read of size 8 > ==27712== at 0x40904A: std::valarray<int>::size() const > (valarray:772) [snip] > ==27712== Address 0x5588760 is 0 bytes inside a block of size 104 > free'd > ==27712== at 0x4A1B17F: operator delete(void*) > (vg_replace_malloc.c:244) "Address [] inside a block of size [] free'd" indicates this is a read-after-free bug: The valarray<int> was delete'd before its size() method was called. Presumably the glibc error is because you also write to some of the released memory -- memory that became part of the heap's free-list structure. Michael Poole |
|
From: Tom H. <to...@co...> - 2009-02-06 19:02:19
|
Ross Boylan wrote: > On Fri, 2009-02-06 at 19:47 +0100, Julian Seward wrote: >>> invalid read. However, there is no indication of why it is invalid. >> Um, it says it is invalid because you are reading freed memory: > I believe those are 2 separate error reports. The addresses are > different, and the indentation seems to indicate they are distinct > items. Am I misreading? Yes - there is an instruction at address 0x40904A which is reading memory at address 0x5588760 that was previously freed. Tom >>> ==27712== Invalid read of size 8 >>> ==27712== at 0x40904A: std::valarray<int>::size() const >>> (valarray:772) >> [...] >>> ==27712== Address 0x5588760 is 0 bytes inside a block of size 104 >>> free'd >>> ==27712== at 0x4A1B17F: operator delete(void*) >>> (vg_replace_malloc.c:244) >>> ==27712== by 0x4968F1: data() (Data_test.cc:123) >>> ==27712== by 0x43903E: boost::unit_test::ut_detail::unused >>> boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>:: >>> invoke<void (*)()>(void (*)()&) (callback.hpp:56) >> [...] >> >> J -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Ross B. <ro...@bi...> - 2009-02-06 19:12:42
|
On Fri, 2009-02-06 at 19:01 +0000, Tom Hughes wrote: > Ross Boylan wrote: > > On Fri, 2009-02-06 at 19:47 +0100, Julian Seward wrote: > >>> invalid read. However, there is no indication of why it is invalid. > >> Um, it says it is invalid because you are reading freed memory: > > I believe those are 2 separate error reports. The addresses are > > different, and the indentation seems to indicate they are distinct > > items. Am I misreading? > > Yes - there is an instruction at address 0x40904A which is reading > memory at address 0x5588760 that was previously freed. > > Tom Thank you. So is the correct reading that the first block gives the stack trace of the call that triggered the error, and the second block gives the stack trace of the earlier code (whose execution is now complete) that freed the memory? Ross > > >>> ==27712== Invalid read of size 8 > >>> ==27712== at 0x40904A: std::valarray<int>::size() const > >>> (valarray:772) > >> [...] > >>> ==27712== Address 0x5588760 is 0 bytes inside a block of size 104 > >>> free'd > >>> ==27712== at 0x4A1B17F: operator delete(void*) > >>> (vg_replace_malloc.c:244) > >>> ==27712== by 0x4968F1: data() (Data_test.cc:123) > >>> ==27712== by 0x43903E: boost::unit_test::ut_detail::unused > >>> boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>:: > >>> invoke<void (*)()>(void (*)()&) (callback.hpp:56) > >> [...] > >> > >> J > > |
|
From: Tom H. <to...@co...> - 2009-02-06 19:18:34
|
Ross Boylan wrote: > On Fri, 2009-02-06 at 19:01 +0000, Tom Hughes wrote: >> Ross Boylan wrote: >>> On Fri, 2009-02-06 at 19:47 +0100, Julian Seward wrote: >>>>> invalid read. However, there is no indication of why it is invalid. >>>> Um, it says it is invalid because you are reading freed memory: >>> I believe those are 2 separate error reports. The addresses are >>> different, and the indentation seems to indicate they are distinct >>> items. Am I misreading? >> Yes - there is an instruction at address 0x40904A which is reading >> memory at address 0x5588760 that was previously freed. >> >> Tom > Thank you. So is the correct reading that the first block gives the > stack trace of the call that triggered the error, and the second block > gives the stack trace of the earlier code (whose execution is now > complete) that freed the memory? Exactly. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Julian S. <js...@ac...> - 2009-02-06 19:20:37
|
> Thank you. So is the correct reading that the first block gives the > stack trace of the call that triggered the error, and the second block > gives the stack trace of the earlier code (whose execution is now > complete) that freed the memory? Yes. J |