I mailed my console log in earlier mail, the systemcall.sendto reporting is
valgrind system call, as the report shows there are 100 errors, all those
addresses are errors?.
On Mon, Jan 18, 2010 at 11:59 AM, Vasanta <[email protected]> wrote:
> The program I am running is pcsc-lite daemon, under idle condition, it runs
> ok, the program size is like 27K, I have USB card reader attached to my box,
> once I use that reader, it calls some third party API from this pscsd daemon
> program, then I can see the program size is keep growing, growing like shows
> below. I thought valgrind can detect where the memory leak, any clues?
>
>
> # ps - eaf | grep pcscd
>
> 5533 root 87328 S valgrind /pfrm2.0/bin/pcscd
>
> # ps - eaf | grep pcscd
>
> 5533 root 221504 S valgrind /pfrm2.0/bin/pcscd
>
> # ps - eaf | grep pcscd
>
> 5533 root 229792 S valgrind /pfrm2.0/bin/pcscd
>
> #
>
> # ps - eaf | grep pcscd
>
> 5533 root 296112 S valgrind /pfrm2.0/bin/pcscd
>
> #
>
> # ps - eaf | grep pcscd
>
> 5533 root 363440 S valgrind /pfrm2.0/bin/pcscd
>
> #
>
> # ps - eaf | grep pcscd
>
> 5533 root 396592 S valgrind /pfrm2.0/bin/pcscd
>
> # ps - eaf | grep pcscd
>
> 5533 root 413168 S valgrind /pfrm2.0/bin/pcscd
>
> 6241 root 1996 R grep pcscd
>
> # ps - eaf | grep pcscd
>
> 5533 root 421456 S valgrind /pfrm2.0/bin/pcscd
>
> 6244 root 2000 R grep pcscd
>
> # ps - eaf | grep pcscd
>
> 5533 root 480512 S valgrind /pfrm2.0/bin/pcscd
>
> # ps - eaf | grep pcscd
>
> 5533 root 488800 S valgrind /pfrm2.0/bin/pcscd
>
> # ps - eaf | grep pcscd
>
> 5533 root 497088 S valgrind /pfrm2.0/bin/pcscd
>
> 6290 root 1996 R grep pcscd
>
> #
>
>
>
> On Mon, Jan 18, 2010 at 11:48 AM, Ashley Pittman <[email protected]>wrote:
>
>>
>> On 18 Jan 2010, at 16:30, Vasanta wrote:
>>
>> thanks. I am able to run now on my embedded target, ERROR SUMMARY shows
>> 1 error, but I cannot see any words like "definitely lost" or "probably
>> lost" like said in Quickstart guide.
>>
>>
>> That is because of the "All heap blocks were freed -- no leaks are
>> possible" line, your program has been (unusually) good and freed all memory.
>>
>> It does look like there is something unusual about your program though as
>> it's reporting this before errors on a different thread. Is the main thread
>> of your program exiting after startup but before the program ends?
>>
>> Ashley,
>>
>> 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==
>>
>> #
>>
>>
>> On Mon, Jan 18, 2010 at 11:12 AM, Ashley Pittman <[email protected]>wrote:
>>
>>>
>>> On 18 Jan 2010, at 15:47, Vasanta wrote:
>>>
>>> Thanks. It is poitnting to the host direxctory which doesnot exist
>>> here, I don't know why it is pointing to host installation dir instead
>>> either /usr/loca/lib/valgrind or /usr/local/bin. is there anyway I can
>>> chnage that path?.
>>>
>>>
>>> I'm afraid don't understand your question. The two ways to change paths
>>> are using the --prefix configure option or the DESTDIR make install option,
>>> the location passed to configure must be the location where the eventual
>>> install is going to be run from as paths are hard coded to this value.
>>>
>>> Ashley,
>>>
>>> On Mon, Jan 18, 2010 at 10:07 AM, Ashley Pittman
>>> <[email protected]>wrote:
>>>
>>>>
>>>> On 18 Jan 2010, at 14:32, Tom Hughes wrote:
>>>>
>>>> > On 18/01/10 14:27, Vasanta wrote:
>>>> >> Looklike when I compile this on host, it is hardcoding the path
>>>> >> into binaries like memcheck-x86-linux and all, if I copy these onto
>>>> my
>>>> >> embedded target, if I run there, it says "memcheck" couldn't start,
>>>> on
>>>> >> target, I copied to /usr/loca/lib abd /usr/local/bin directories,
>>>> when I
>>>> >> execute, path not correct, how can I fix this path?.
>>>> >
>>>> > As I have now told you twice, you need to put the binaries in the same
>>>> > place on the target as they are in when you install on the build
>>>> > machine. The exact same place. Not something a bit like the same
>>>> place.
>>>> >
>>>> > The reason for that, as you have discovered, is that the paths are
>>>> fixed
>>>> > in at build time so that the launcher process (the valgrind binary)
>>>> will
>>>> > look in a specific place for the tools.
>>>> >
>>>> > So the things in /usr/local/lib/valgrind on the build machine need to
>>>> be
>>>> > copied to /usr/local/lib/valgrind on the target machine, not to
>>>> > /usr/local/lib or anywhere else.
>>>>
>>>> Autogen provides a mechanism for doing this kind of install, what it
>>>> calls a 'staged install'. You have to run the configure with the prefix
>>>> you
>>>> want on the target machine but then when running the make install command
>>>> use DESTDIR=/path/to/stage/install on the command line. It's then a simple
>>>> case of taring up $DESTDIR on the build machine and untaring it to $PREFIX
>>>> on the target machine.
>>>>
>>>> Using this method will help ensure you pick up all the files required
>>>> and that they keep their appropriate permissions. It also doesn't require
>>>> root for the make install step. Hopefully it will simplify the process and
>>>> help you find your problem.
>>>>
>>>> http://www.gnu.org/prep/standards/html_node/DESTDIR.html
>>>>
>>>> Ashley,
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Throughout its 18-year history, RSA Conference consistently attracts the
>>>> world's best and brightest in the field, creating opportunities for
>>>> Conference
>>>> attendees to learn about information security's most important issues
>>>> through
>>>> interactions with peers, luminaries and emerging and established
>>>> companies.
>>>> http://p.sf.net/sfu/rsaconf-dev2dev
>>>> _______________________________________________
>>>> Valgrind-users mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>>>
>>>
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Throughout its 18-year history, RSA Conference consistently attracts the
>> world's best and brightest in the field, creating opportunities for
>> Conference
>> attendees to learn about information security's most important issues
>> through
>> interactions with peers, luminaries and emerging and established
>> companies.
>>
>> http://p.sf.net/sfu/rsaconf-dev2dev_______________________________________________
>> Valgrind-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>>
>>
>
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
