Re: [Valgrind-users] Suppressions

[Nicholas N. <nj...@ca...>]

On Tue, 10 Jun 2003, Alex Ivershen wrote:

> I am having troubles suppressing certain messages, may be the reason is that the
> callstack contains C++ member fucntions and I am writing them in a wrong way in
> the suppression file ...  Valgrind reads the suppression file just fine, but
> errors and memory leaks still pop up. BTW, I am using 1.9.6.

Easy solution:  grab CVS head from Sourceforge, build as per README
instructions, use the --gen-suppressions=yes option.

More details below.

> Here is an error that I am trying to suppress:
>
> ==17423== Syscall param ioctl(CDROMREADTOCENTRY (cdte_track, char)) contains
> uninitialised or unaddressable byte(s)
> ==17423==    at 0x40387D04: __GI___ioctl (in /lib/libc-2.3.2.so)
> ==17423==    by 0x80A8145: KIpmPerThreadData::KIpmPerThreadData(int, int, void
> (*)(void *, IpmCongestionType), void *) (../KIpmPerThreadData.cc:208)
> ==17423==    by 0x80A6B52: ipmInit(void) (../common/IpmPerThreadData.h:183)
> ==17423==    by 0x8060C6A: initProcessControl(char const *, unsigned long,
> short, short) (../common/ProcessControl.cc:249)
> ==17423==    Address 0x2 is not stack'd, malloc'd or free'd
>
> Here is a suppression entry:
>
> {
>     ioctl_CDROMREADTOCENTRY/ipmInit
>     Addrcheck,Memcheck:Cond
>     fun:__GI___ioctl
>     fun:KIpmPerThreadData::KIpmPerThreadData
>     fun:ipmInit
> }

1. C++ names must be _mangled_.  Use --demangle=no to find them out.

2. "Cond" is the wrong type, you want "Syscall" (or something similar, I
can't remember the exact name now).

3. "Syscall" type suppressions (confusingly) needs an extra line before
the first "fun:" line, which I think (off the top of my head) specifies
which argument is the problem.

> Here is a memory leak I am trying to suppress:
>
> ==17423== 12 bytes in 1 blocks are possibly lost in loss record 4 of 46
> ==17423==    at 0x4015E310: malloc (vg_clientfuncs.c:103)
> ==17423==    by 0x80BB74B: __builtin_new (../../gcc-2.95.3/gcc/cp/new1.cc:77)
> ==17423==    by 0x8063369: ProcessorConfigDb::BuildProcessorControlName(void)
> (../include/NsDestList.h:173)
> ==17423==    by 0x8065193: ProcessorConfigDb::UpdateSystemNames(short)
> (../common/ProcessorConfigDb.cc:873)
>
> Here is a suppression entry (there are similar errors from similar functions,
> hence the wildcard)
>
> {
>     ProcessorConfigDb/BuildDbServerName
>     Memcheck:Leak
>     fun:malloc
>     fun:__builtin_new
>     fun:ProcessorConfigDb::Build*
> }

This one's closer, again I think its the mangling that's the problem.

N