views:

118

answers:

3

When I used valgrind to help debug an app I was working on I notice a huge about of noise which seems to be complaining about standard libraries. As a test I did this;

echo 'int main() {return 0;}' | gcc -x c -o test -

Then I did this;

valgrind ./test

==1096== Use of uninitialised value of size 8
==1096==    at 0x400A202: _dl_new_object (in /lib64/ld-2.10.1.so)
==1096==    by 0x400607F: _dl_map_object_from_fd (in /lib64/ld-2.10.1.so)
==1096==    by 0x4007A2C: _dl_map_object (in /lib64/ld-2.10.1.so)
==1096==    by 0x400199A: map_doit (in /lib64/ld-2.10.1.so)
==1096==    by 0x400D495: _dl_catch_error (in /lib64/ld-2.10.1.so)
==1096==    by 0x400189E: do_preload (in /lib64/ld-2.10.1.so)
==1096==    by 0x4003CCD: dl_main (in /lib64/ld-2.10.1.so)
==1096==    by 0x401404B: _dl_sysdep_start (in /lib64/ld-2.10.1.so)
==1096==    by 0x4001471: _dl_start (in /lib64/ld-2.10.1.so)
==1096==    by 0x4000BA7: (within /lib64/ld-2.10.1.so)
* large block of similar snipped *
==1096== Use of uninitialised value of size 8
==1096==    at 0x4F35FDD: (within /lib64/libc-2.10.1.so)
==1096==    by 0x4F35B11: (within /lib64/libc-2.10.1.so)
==1096==    by 0x4A1E61C: _vgnU_freeres (vg_preloaded.c:60)
==1096==    by 0x4E5F2E4: __run_exit_handlers (in /lib64/libc-2.10.1.so)
==1096==    by 0x4E5F354: exit (in /lib64/libc-2.10.1.so)
==1096==    by 0x4E48A2C: (below main) (in /lib64/libc-2.10.1.so)
==1096==
==1096== ERROR SUMMARY: 3819 errors from 298 contexts (suppressed: 876 from 4)
==1096== malloc/free: in use at exit: 0 bytes in 0 blocks.
==1096== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==1096== For counts of detected errors, rerun with: -v
==1096== Use --track-origins=yes to see where uninitialised values come from
==1096== All heap blocks were freed -- no leaks are possible.

You can see the full result here: http://pastebin.com/gcTN8xGp

I have two questions; firstly is there a way to suppress all the noise?

--show-below-main is set to no by default, but there doesn't appear to be a --show-after-main equivalent.

+8  A: 

You can suppress the output by appending

{
   ld error suppression
   Memcheck:Cond
   fun:dl_main
   fun:_dl_sysdep_start
   fun:_dl_start
   obj:/lib64/ld-2.10.1.so
}

to /usr/lib/valgrind/default.supp (or defining your own suppression file).

It appears to be a known linker/loader bug, at least to Debian & Arch Linux developers; I'm unsure about the rest, as well as their planned course of action.

Michael Foukarakis
This issue was with using a glibc newer than what Valgrind was familiar with. +1 for pointing me in the right direction.
Chris Huang-Leaver
+3  A: 

Upgrade to Valgrind 3.5.0 or better. Amongst other things the default .supp files have been updated.

Chris Huang-Leaver
+1  A: 

I have these symptoms from time to time, and the solution is always to upgrade my valgrind and libc packages to be in sync. The nice little elves at Debian take care of the rest.

Norman Ramsey