|
From: Nicholas N. <nj...@ca...> - 2003-06-10 20:50:28
|
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
|