|
From: Vesko P. <ves...@ho...> - 2006-07-27 14:43:48
|
Hello,
An error (the leak) in a simple test program isn't suppressed. I've looked
carefully at the Valgrind documentation, but I don't see to be doing
anything wrong. Here's an exact log of my actions:
$ cat main.cc
#include <iostream>
int main()
{
char *s = new char[1];
std::cout << "valgrind suppression test";
return 0;
}
$ g++ -g main.cc
valgrind --leak-check=full --gen-suppressions=all ./a.out
==5518== Memcheck, a memory error detector.
==5518== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==5518== Using LibVEX rev 1606, a library for dynamic binary translation.
==5518== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==5518== Using valgrind-3.2.0, a dynamic binary instrumentation framework.
==5518== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==5518== For more details, rerun with: -v
==5518==
valgrind suppression test==5518==
==5518== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 1)
==5518== malloc/free: in use at exit: 1 bytes in 1 blocks.
==5518== malloc/free: 1 allocs, 0 frees, 1 bytes allocated.
==5518== For counts of detected errors, rerun with: -v
==5518== searching for pointers to 1 not-freed blocks.
==5518== checked 100,712 bytes.
==5518==
==5518== 1 bytes in 1 blocks are definitely lost in loss record 1 of 1
==5518== at 0x4004D1D: operator new[](unsigned) (vg_replace_malloc.c:195)
==5518== by 0x8048741: main (main.cc:6)
{
<insert a suppression name here>
Memcheck:Leak
fun:_vgrZU_libstdcZpZpZa__Znaj
fun:main
}
==5518==
==5518== LEAK SUMMARY:
==5518== definitely lost: 1 bytes in 1 blocks.
==5518== possibly lost: 0 bytes in 0 blocks.
==5518== still reachable: 0 bytes in 0 blocks.
==5518== suppressed: 0 bytes in 0 blocks.
==5518== Reachable blocks (those to which a pointer was found) are not
shown.
==5518== To see them, rerun with: --show-reachable=yes
Then, I copy the suppression to a file named test.supp and re-run valgrind
specifying the file, i.e:
$ cat test.supp
{
<insert a suppression name here>
Memcheck:Leak
fun:_vgrZU_libstdcZpZpZa__Znaj
fun:main
}
$ valgrind --leak-check=full --suppressions=test.supp ./a.out
==5533== Memcheck, a memory error detector.
==5533== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==5533== Using LibVEX rev 1606, a library for dynamic binary translation.
==5533== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==5533== Using valgrind-3.2.0, a dynamic binary instrumentation framework.
==5533== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==5533== For more details, rerun with: -v
==5533==
valgrind suppression test==5533==
==5533== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 1)
==5533== malloc/free: in use at exit: 1 bytes in 1 blocks.
==5533== malloc/free: 1 allocs, 0 frees, 1 bytes allocated.
==5533== For counts of detected errors, rerun with: -v
==5533== searching for pointers to 1 not-freed blocks.
==5533== checked 100,712 bytes.
==5533==
==5533== 1 bytes in 1 blocks are definitely lost in loss record 1 of 1
==5533== at 0x4004D1D: operator new[](unsigned) (vg_replace_malloc.c:195)
==5533== by 0x8048741: main (main.cc:6)
==5533==
==5533== LEAK SUMMARY:
==5533== definitely lost: 1 bytes in 1 blocks.
==5533== possibly lost: 0 bytes in 0 blocks.
==5533== still reachable: 0 bytes in 0 blocks.
==5533== suppressed: 0 bytes in 0 blocks.
==5533== Reachable blocks (those to which a pointer was found) are not
shown.
==5533== To see them, rerun with: --show-reachable=yes
When generating the suppressions, I've tried adding the "--demangle=no"
option just in case, although it isn't needed, i.e. "valgrind
--leak-check=full --gen-suppressions=all --demangle=no ./a.out". Regardless,
no result.
The system is Fedora Core 3 x86; gcc 3.4.4.
|
|
From: Igmar P. <mai...@jd...> - 2006-07-28 06:54:58
|
> {
> <insert a suppression name here>
> Memcheck:Leak
> fun:_vgrZU_libstdcZpZpZa__Znaj
> fun:main
> }
It isn't demangling where it should. You're not the only one : I see the
exact output. What gcc version are you using ? It might be
compiler-related..
Regards,
Igmar
|
|
From: Nicholas N. <nj...@cs...> - 2006-07-28 08:38:56
|
On Fri, 28 Jul 2006, Igmar Palsenberg wrote:
>> {
>> <insert a suppression name here>
>> Memcheck:Leak
>> fun:_vgrZU_libstdcZpZpZa__Znaj
>> fun:main
>> }
>
> It isn't demangling where it should. You're not the only one : I see the
> exact output.
No, I believe the suppression entries are meant to be in mangled form.
So it must be something else going wrong.
Nick
|
|
From: Igmar P. <mai...@jd...> - 2006-07-28 09:33:06
|
> >> {
> >> <insert a suppression name here>
> >> Memcheck:Leak
> >> fun:_vgrZU_libstdcZpZpZa__Znaj
> >> fun:main
> >> }
> >
> > It isn't demangling where it should. You're not the only one : I see the
> > exact output.
>
> No, I believe the suppression entries are meant to be in mangled form.
> So it must be something else going wrong.
I see.. The mangled form is all there is in the binary. Isn't it an
option to get all symbol form the symtable, demangle them, and then do the
function name compares ? You're less dependant on the exact compiler
version, since mangling had several form in al least the gcc history.
> Nick
Igmar
|
|
From: Dennis L. <pla...@pr...> - 2006-07-28 11:49:42
|
Am Donnerstag, den 27.07.2006, 14:43 +0000 schrieb Vesko Peev:
> Hello,
> $ cat test.supp
> {
> <insert a suppression name here>
> Memcheck:Leak
> fun:_vgrZU_libstdcZpZpZa__Znaj
> fun:main
> }
Thats a strange symbol, my c++filt from gcc 4.x doesnt understand it.
Can you try piping it through c++filt on your machine and look if it
gets demangled? Afaik the mangled form of new[] should be _Znaj ... Can
you replace that symbol by _Znaj and try again? maybe for some reason V
gives a wrong symbol?
greets
Dennis
PS: Sorry if this message appears twice, I have little mailserver problems.
|
|
From: Igmar P. <mai...@jd...> - 2006-07-28 12:05:10
|
> Thats a strange symbol, my c++filt from gcc 4.x doesnt understand it. Mine doesn't either. It's also not in the binary's symbol table. > Can you try piping it through c++filt on your machine and look if it > gets demangled? Afaik the mangled form of new[] should be _Znaj ... Can > you replace that symbol by _Znaj and try again? maybe for some reason V > gives a wrong symbol? It's refering to the new operator override symbol inside VG, not the one inside libstdc++. _vgrZU_libstdcZpZpZa__Znaj is inside vgpreload_memcheck.so on this installation (SVN rev 5993). Igmar |
|
From: Dennis L. <pla...@pr...> - 2006-07-28 21:47:24
|
Am Donnerstag, den 27.07.2006, 14:43 +0000 schrieb Vesko Peev:
> Hello,
> $ cat test.supp
> {
> <insert a suppression name here>
> Memcheck:Leak
> fun:_vgrZU_libstdcZpZpZa__Znaj
> fun:main
> }
Thats a strange symbol, my c++filt from gcc 4.x doesnt understand it.
Can you try piping it through c++filt on your machine and look if it
gets demangled? Afaik the mangled form of new[] should be _Znaj ... Can
you replace that symbol by _Znaj and try again? maybe for some reason V
gives a wrong symbol?
greets
Dennis
|
|
From: Julian S. <js...@ac...> - 2006-07-28 21:57:59
|
On Friday 28 July 2006 10:58, Dennis Lubert wrote:
> Am Donnerstag, den 27.07.2006, 14:43 +0000 schrieb Vesko Peev:
> > Hello,
> >
> > $ cat test.supp
> > {
> > <insert a suppression name here>
> > Memcheck:Leak
> > fun:_vgrZU_libstdcZpZpZa__Znaj
> > fun:main
> > }
>
> Thats a strange symbol, my c++filt from gcc 4.x doesnt understand it.
> Can you try piping it through c++filt on your machine and look if it
> gets demangled? Afaik the mangled form of new[] should be _Znaj ... Can
> you replace that symbol by _Znaj and try again? maybe for some reason V
> gives a wrong symbol?
Just to clear up this confusion .. the _vgrZU_ is something that
V understands as giving this symbol special significance. The
overall meaning of the symbol is
I am the replacement for _Znaj in any object with ELF soname
matching "libstdc++*". Whenever you see a jump to any symbol
_Znaj in any object with soname matching "libstdc++*", route it
to me instead.
Since _Znaj is the mangled C++ name for operator new[](unsigned int),
the entire symbol _vgrZU_libstdcZpZpZa__Znaj is the name of V's
replacement for operator new[](unsigned int), as defined in
coregrind/m_replacemalloc/vg_replace_malloc.c.
None of which explains why the suppression doesn't work. I think
you should file a formal bug report.
J
|