0

I'm using massif to debug heap increasing issue with a binary program which is running long long time. But it report:

valgrind: m_mallocfree.c:280 (mk_plain_bszB): Assertion 'bszB != 0' failed.
valgrind: This is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap metadata.  If you fix any
invalid writes reported by Memcheck, this assertion failure will
probably go away.  Please try that before reporting this as a bug.
host stacktrace:
==21766==    at 0x58007769: show_sched_status_wrk (in /usr/lib64/valgrind/massif-amd64-linux)
==21766==    by 0x58007A44: report_and_quit (in /usr/lib64/valgrind/massif-amd64-linux)
==21766==    by 0x58007C77: vgPlain_assert_fail (in /usr/lib64/valgrind/massif-amd64-linux)
==21766==    by 0x58013D01: vgPlain_arena_free (in /usr/lib64/valgrind/massif-amd64-linux)
==21766==    by 0x5805CAE2: do_client_request (in /usr/lib64/valgrind/massif-amd64-linux)
==21766==    by 0x5805DCFE: vgPlain_scheduler (in /usr/lib64/valgrind/massif-amd64-linux)
==21766==    by 0x58011560: final_tidyup (in /usr/lib64/valgrind/massif-amd64-linux)
==21766==    by 0x5801191B: shutdown_actions_NORETURN (in /usr/lib64/valgrind/massif-amd64-linux)
==21766==    by 0x5808F42C: run_a_thread_NORETURN (in /usr/lib64/valgrind/massif-amd64-linux)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 21766)
==21766==    at 0x4A06F16: free (vg_replace_malloc.c:529)
==21766==    by 0x3CD630C24A: free_mem (in /lib64/libc-2.5.so)
==21766==    by 0x3CD630BE41: __libc_freeres (in /lib64/libc-2.5.so)
==21766==    by 0x480368A: _vgnU_freeres (vg_preloaded.c:77)
==21766==    by 0x3CD6233224: exit (exit.c:90)
==21766==    by 0x3CD621D9FA: (below main) (libc-start.c:262)

So I tryed valgrind --tool=memcheck -v, and it report:

==21789== HEAP SUMMARY:
==21789==     in use at exit: 0 bytes in 0 blocks
==21789==   total heap usage: 7,015 allocs, 7,016 frees, 805,222 bytes allocated
==21789==
==21789== All heap blocks were freed -- no leaks are possible
==21789==
==21789== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 4)
==21789==
==21789== 1 errors in context 1 of 1:
==21789== Invalid free() / delete / delete[] / realloc()
==21789==    at 0x4A08B56: free (vg_replace_malloc.c:529)
==21789==    by 0x3CD630C24A: free_mem (in /lib64/libc-2.5.so)
==21789==    by 0x3CD630BE41: __libc_freeres (in /lib64/libc-2.5.so)
==21789==    by 0x480368A: _vgnU_freeres (vg_preloaded.c:77)
==21789==    by 0x3CD6233224: exit (exit.c:90)
==21789==    by 0x3CD621D9FA: (below main) (libc-start.c:262)
==21789==  Address 0x6374c98 is in a rw- anonymous segment
==21789==
--21789--
--21789-- used_suppression:      6 dl-hack3 /usr/lib64/valgrind/default.supp:1239
==21789==
==21789== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 4)

I got no idea for something error below main.

jww
  • 97,681
  • 90
  • 411
  • 885
haha
  • 49
  • 1
  • 2
  • Its too bad Valgrind Memcheck does not point to something interesting. Does Memcheck shown above call any code you have written? Or is it boilerplate library code? Maybe avoiding `/usr/lib64/valgrind/default.supp` will show more useful information. Strange things happen in dtor and fini functions. Some programmers feel they can be very sloppy on program exit. Do any of the cleanup routines look like they are your functions? – jww Dec 20 '17 at 04:14

1 Answers1

3

For tools that are replacing malloc/free/.. (e.g. memcheck and massif), valgrind runs by default glibc provided functions that release the memory allocated for e.g. the c++ runtime or some glibc/dynamic loader data structures. This allows a 'memory leak free' report. However, it looks like the glibc cleaner is trying to free some memory that was allocated by something that valgrind did not intercept (maybe a 'too early' allocation? This is unclear).

Two things to do:

  • run with --run-libc-freeres=no --run-cxx-freeres=no to bypass the problem. (you might then see memcheck complaining about some memory still allocated)
  • file a bug about the above on valgrind bugzilla, giving all tne needed details such as gcc version, glibc version, distribution, valgrind version, ...
phd
  • 3,669
  • 1
  • 11
  • 12