Hi! Pierre Habouzit schrieb: > > The following false positive (I think) from libc prints like this in > > valgrind 1%3a3.4.1-1 with --demangle=no: > > > > ==24358== Invalid free() / delete / delete[] > > ==24358== at 0x4C2261F: _vgrZU_libcZdsoZa_free (vg_replace_malloc.c:323) > > ==24358== by 0x514ADEA: (within /lib/libc-2.9.so) > > ==24358== by 0x514A981: (within /lib/libc-2.9.so) > > ==24358== by 0x4A1E560: _vgnU_freeres (vg_preloaded.c:60) > > ==24358== by 0x507E4B4: exit (in /lib/libc-2.9.so) > > ==24358== by 0x50665CC: __libc_start_main (in /lib/libc-2.9.so) > > ==24358== Address 0x4039178 is not stack'd, malloc'd or (recently) free'd > > ==24358== > > ==24358== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- y
> > { > > <insert a suppression name here> > > Memcheck:Free > > fun:_vgrZU_libcZdsoZa_free > > obj:/lib/libc-2.9.so > > obj:/lib/libc-2.9.so > > fun:_vgnU_freeres > > fun:exit > > fun:__libc_start_main > > } > > But with 1%3a3.5.0-1 it looks like this: > > > > ==24071== Invalid free() / delete / delete[] > > ==24071== at 0x4C21DBC: free (vg_replace_malloc.c:325) > > ==24071== by 0x5149DEA: ??? (in /lib/libc-2.9.so) > > ==24071== by 0x5149981: ??? (in /lib/libc-2.9.so) > > ==24071== by 0x4A1E590: _vgnU_freeres (vg_preloaded.c:62) > > ==24071== by 0x507D4B4: exit (in /lib/libc-2.9.so) > > ==24071== by 0x50655CC: (below main) (in /lib/libc-2.9.so) > > ==24071== Address 0x4038cd0 is not stack'd, malloc'd or (recently) free'd > > ==24071== > > ==24071== > > ==24071== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- y > > { > > <insert_a_suppression_name_here> > > Memcheck:Free > > fun:free > > obj:/lib/libc-2.9.so > > obj:/lib/libc-2.9.so > > fun:_vgnU_freeres > > fun:exit > > fun:(below main) > > } > > I fail to see where the problem is since the sole difference is 'free' > which should be 'free' (it's a C symbol) and not _vgrZU_libcZdsoZa_free > a all. there's also a difference between __libc_start_main vs. (below main). I think you're basically saying that it was a bug before and is fixed since 3.5.0? The manpage states: ,---- An important fact about demangling is that function names mentioned in suppressions files should be in their mangled form. Valgrind does not demangle function names when searching for applicable suppressions, because to do otherwise would make suppression file contents dependent on the state of Valgrind's demangling machinery, and also slow down suppression matching. `---- Which is why I give --demangle=no when looking for applicable suppressions. The difference in the output between 3.4 and 3.5 looks like _vgrZU_libcZdsoZa_free and __libc_start_main are the mangled forms. Also when I enter the supression as output by 3.5., the error is still printed, i.e. not supressed, so there is at least an inconsistency between matching and printing of supressions here. I've resorted to --run-libc-freeres=no to get rid of those false positives, and fortunately I don't get false leak reports, but since libc-freeres doesn't segfault, it doesn't seem like the right thing to do. > Are you sure this is a bug? Pretty sure. -- Friedrich Delgado <frie...@nomaden.org> TauPan on Ircnet and Freenode ;) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org