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
