Re: [Valgrind-users] Fwd: valgrind error - "failed to start tool 'memcheck' for platform x86-linux

[Ashley P. <as...@pi...>]

The pid in the valgrind output (7346) does not match the one from ps (7353), it looks like your process is forking into the background to detach from the terminal, is there any way to prevent this behaviour?  Most daemons have a command line option to disable it which will simplify using valgrind.  Otherwise you might want to look into using the --trace-children=yes option to valgrind.

Valgrind normally only reports leaks when a program exits, if it's a deamon you'll have to stop it after a period of time to see any memory leaks.

Ashley,

On 20 Jan 2010, at 15:46, Vasanta wrote:

> google says "Uninitilised data" with valgrind tool is Ok, there is no harm with that at all.
>  
> My biggest memory leak is with first e-mail I sent (pasted again below), I can see pcscd size keep growing, but valgrind looklike can't catch the issue, I did compile with -g also. do I need any other tool?
>  
>  
> valgrind --leak-check=yes /pfrm2.0/bin/pcscd &
> 
> ==7346== Memcheck, a memory error detector
> 
> ==7346== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
> 
> ==7346== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
> 
> ==7346== Command: /pfrm2.0/bin/pcscd
> 
> ==7346==
> 
> # ==7346== Invalid free() / delete / delete[]
> 
> ==7346== at 0x4021520: free (vg_replace_malloc.c:325)
> 
> ==7346== by 0x413C0ED: ??? (in /lib/libc-2.5.so)
> 
> ==7346== by 0x413BC71: ??? (in /lib/libc-2.5.so)
> 
> ==7346== by 0x401D4C3: _vgnU_freeres (vg_preloaded.c:62)
> 
> ==7346== by 0x40FE9CB: daemon (in /lib/libc-2.5.so)
> 
> ==7346== by 0x804E7B6: main (pcscdaemon.c:407)
> 
> ==7346== Address 0x416d2c0 is not stack'd, malloc'd or (recently) free'd
> 
> ==7346==
> 
> ==7346==
> 
> ==7346== HEAP SUMMARY:
> 
> ==7346== in use at exit: 0 bytes in 0 blocks
> 
> ==7346== total heap usage: 1 allocs, 2 frees, 352 bytes allocated
> 
> ==7346==
> 
> ==7346== All heap blocks were freed -- no leaks are possible
> 
> ==7346==
> 
> ==7346== For counts of detected and suppressed errors, rerun with: -v
> 
> ==7346== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 9 from 9)
> 
> ==7346== Warning: noted but unhandled ioctl 0x5514 with no size/direction hints
> 
> ==7346== This could cause spurious value errors to appear.
> 
> ==7346== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
> 
> ==7346== Thread 4:
> 
> ==7346== Syscall param write(buf) points to uninitialised byte(s)
> 
> ==7346== at 0x4039DA1: ??? (in /lib/libpthread-2.5.so)
> 
> ==7346== by 0x8055AD3: MSGFunctionDemarshall (winscard_svc.c:449)
> 
> ==7346== by 0x8055E98: ContextThread (winscard_svc.c:156)
> 
> ==7346== by 0x4033282: start_thread (in /lib/libpthread-2.5.so)
> 
> ==7346== by 0x4101C6D: clone (in /lib/libc-2.5.so)
> 
> ==7346== Address 0x5da9bcc is on thread 4's stack
> 
> ==7346==
> 
> #
> 
> # ps -eaf | grep pcscd
> 
> 7353 root 321564 S valgrind --leak-check=yes /pfrm2.0/bin/pcscd
> 
> # ps -eaf | grep pcscd
> 
> 7353 root 338140 S valgrind --leak-check=yes /pfrm2.0/bin/pcscd
> 
> # ps -eaf | grep pcscd
> 
> 7353 root 346428 S valgrind --leak-check=yes /pfrm2.0/bin/pcscd
> 
> 7774 root 1996 R grep pcscd
> 
> # ps -eaf | grep pcscd
> 
> 7353 root 354716 S valgrind --leak-check=yes /pfrm2.0/bin/pcscd
> 
> 7777 root 1996 R grep pcscd
> 
> # ps -eaf | grep pcscd
> 
> 7353 root 363004 S valgrind --leak-check=yes /pfrm2.0/bin/pcscd
> 
>  
>  
> 
> 
>  
> On Tue, Jan 19, 2010 at 2:27 PM, Vasanta <vt...@gm...> wrote:
> this is the code which calls sendto - I added memset before init variables at line 3, didn't help.
>  
>   UMI_REQ_INFO *  pUmiReq;
>     unsigned int    reqBufSize;
>  
>  
>  pUmiReq = (UMI_REQ_INFO *)pBuf;
>         pUmiReq->cmd    = cmd;
>         pUmiReq->srcId  = pSrcCtx->myId;
>         pUmiReq->reqOpt = reqOpt;
>         pUmiReq->reqId  = reqId;
>         pUmiReq->req    = 1;
>  
>         if (sendto (pSrcCtx->sockFd, pUmiReq, reqBufSize,
>                     0, (struct sockaddr *) &destId, sizeof(UMI_COMP_ID)) == -1)
>             {
> 
> 
> On Tue, Jan 19, 2010 at 9:27 AM, Ashley Pittman <as...@pi...> wrote:
> 
> The error shown is nothing to do with malloc, you are passing uninitialised data to the kernel in the sendto() system call.
> 
> Ashley,
> 
> On 19 Jan 2010, at 14:24, Vasanta wrote:
> 
>> I looked into adpModuleDebug which was shown by stack trace - I don't have any mallocs except printfs/vsnprintf/sprintf (to log msgs into syslog)
>> 
>>  
>> On Mon, Jan 18, 2010 at 4:49 PM, Ashley Pittman <as...@pi...> wrote:
>> 
>> On 18 Jan 2010, at 21:42, Vasanta wrote:
>> 
>>> Thanks Ashley. on my target I don't have GDB, I have to copy GDB from host, also I have to compile my code with -g option to debug that routine with gdb to findout where exactly it is.
>> 
>> You don't need to have gdb installed for Valgrind to work, it just uses the same debug info from the application.  If gdb can show you line numbers valgrind should also be able to.
>> 
>>> This is the first time I using this valgrind, I want to confirm for these few lines below, always the error is: line below "sendto" line right, which is pointed with red color text below?.
>> 
>> This is the stack trace where uninitialised data is passed into the kernel.
>> 
>>>  ==2107== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
>>> ==2107== at 0x43B731E: sendto (in /lib/libpthread-2.5.so)               <----- Pthread routine
>>> 
>>> ==2107== by 0x439A019: adpModuleDebug (in /pfrm2.0/lib/libi386adaptos.so)   <--- My module memory corruption
>>> 
>>> ==2107== by 0x8059C4D: cacStatsUpdate (in /pfrm2.0/bin/cacd)
>>> 
>>> ==2107== by 0x80524A4: cacdRun (in /pfrm2.0/bin/cacd)
>>> 
>>> ==2107== by 0x805286F: main (in /pfrm2.0/bin/cacd)
>>> 
>>> ==2107== Address 0xbefd44cc is on thread 1's stack
>>> 
>> 
> 
> 
>