|
From: Vasanta <vt...@gm...> - 2010-01-15 19:28:51
|
Hi, I installed valgrind libraries and binaries on x86 based embedded target, I am getting "valgrind error - "failed to start tool 'memcheck' for platform x86-linux" no such file or directory". I can see memcheck-x86-linux file under lib, but it keeps reporting everytime. copied all lib and bin files which are generated after I compiled valgrind package, when I run my exe with valgrind, I am getting above error, any idea? lib/ -rw-r--r-- 1 0 0 27934 default.supp -rwxr-xr-x 1 0 0 4636305 cachegrind-x86-linux -rwxr-xr-x 1 0 0 4891451 callgrind-x86-linux -rwxr-xr-x 1 0 0 4857510 drd-x86-linux -rwxr-xr-x 1 0 0 4519362 exp-bbv-x86-linux -rwxr-xr-x 1 0 0 4729657 exp-ptrcheck-x86-linux -rwxr-xr-x 1 0 0 4837460 helgrind-x86-linux -rwxr-xr-x 1 0 0 4529944 lackey-x86-linux -rwxr-xr-x 1 0 0 4568883 massif-x86-linux -rwxr-xr-x 1 0 0 5040139 memcheck-x86-linux -rwxr-xr-x 1 0 0 4509675 none-x86-linux -rwxr-xr-x 1 0 0 72136 vgpreload_memcheck-x86-linux.so -rwxr-xr-x 1 0 0 37223 vgpreload_massif-x86-linux.so -rwxr-xr-x 1 0 0 107935 vgpreload_helgrind-x86-linux.so -rwxr-xr-x 1 0 0 45354 vgpreload_exp-ptrcheck-x86-linux.so -rwxr-xr-x 1 0 0 170657 vgpreload_drd-x86-linux.so -rwxr-xr-x 1 0 0 6765 vgpreload_core-x86-linux.so # bin/ rwxr-xr-x 1 0 0 40959 callgrind_annotate -rwxr-xr-x 1 0 0 13662 callgrind_control -rwxr-xr-x 1 0 0 32064 cg_annotate -rwxr-xr-x 1 0 0 42942 cg_merge -rwxr-xr-x 1 0 0 24211 ms_print -rwxr-xr-x 1 0 0 8531 no_op_client_for_valgrind -rwxr-xr-x 1 0 0 30823 valgrind -rwxr-xr-x 1 0 0 18887 valgrind-listener # valgrind /pfrm2.0/bin/pcscd valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory # # pwd /pfrm2.0/lib # ls -l memcheck* -rwxr-xr-x 1 0 0 5040139 memcheck-x86-linux # # # valgrind --tool=memcheck /pfrm2.0/bin/pcscd valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory # # valgrind --tool=memcheck-x86-linux /pfrm2.0/bin/pcscd valgrind: failed to start tool 'memcheck-x86-linux' for platform 'x86-linux': No such file or directory thanks. |
|
From: Tom H. <to...@co...> - 2010-01-15 19:58:47
|
On 15/01/10 19:28, Vasanta wrote: > I installed valgrind libraries and binaries on x86 based embedded > target, I am getting "valgrind error - "failed to start tool 'memcheck' > for platform x86-linux" no such file or directory". I can see > memcheck-x86-linux file under lib, but it keeps reporting everytime. > > copied all lib and bin files which are generated after I compiled > valgrind package, when I run my exe with valgrind, I am getting above > error, any idea? You need to put files the same directory on the target machine that they were in on the build machine (probably /usr/lib/valgrind) or valgrind won't find them. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Vasanta <vt...@gm...> - 2010-01-15 21:23:02
|
also I copied all binaries and libraries into single directory, then I tried to execute "valgrind" command, I am getting same error as before. also I copied memcheck-x86-linux as memcheck. # ls -l -rwxr-xr-x 1 0 0 40959 callgrind_annotate -rwxr-xr-x 1 0 0 13662 callgrind_control -rwxr-xr-x 1 0 0 32064 cg_annotate -rwxr-xr-x 1 0 0 42942 cg_merge -rwxr-xr-x 1 0 0 24211 ms_print -rwxr-xr-x 1 0 0 8531 no_op_client_for_valgrind -rwxr-xr-x 1 0 0 30823 valgrind -rwxr-xr-x 1 0 0 18887 valgrind-listener -rwxr-xr-x 1 0 0 4636305 cachegrind-x86-linux -rwxr-xr-x 1 0 0 4891451 callgrind-x86-linux -rw-r--r-- 1 0 0 27934 default.supp -rwxr-xr-x 1 0 0 4857510 drd-x86-linux -rwxr-xr-x 1 0 0 4519362 exp-bbv-x86-linux -rwxr-xr-x 1 0 0 4729657 exp-ptrcheck-x86-linux -rwxr-xr-x 1 0 0 4837460 helgrind-x86-linux -rwxr-xr-x 1 0 0 4529944 lackey-x86-linux -rwxr-xr-x 1 0 0 4568883 massif-x86-linux -rwxr-xr-x 1 0 0 5040139 memcheck-x86-linux -rwxr-xr-x 1 0 0 4509675 none-x86-linux -rwxr-xr-x 1 0 0 6765 vgpreload_core-x86-linux.so -rwxr-xr-x 1 0 0 170657 vgpreload_drd-x86-linux.so -rwxr-xr-x 1 0 0 45354 vgpreload_exp-ptrcheck-x86-linux.so -rwxr-xr-x 1 0 0 107935 vgpreload_helgrind-x86-linux.so -rwxr-xr-x 1 0 0 37223 vgpreload_massif-x86-linux.so -rwxr-xr-x 1 0 0 72136 vgpreload_memcheck-x86-linux.so -rwxr-xr-x 1 0 0 5040139 memcheck # # valgrind /pfrm2.0/bin/pcscd valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory # On Fri, Jan 15, 2010 at 2:58 PM, Tom Hughes <to...@co...> wrote: > On 15/01/10 19:28, Vasanta wrote: > > I installed valgrind libraries and binaries on x86 based embedded >> target, I am getting "valgrind error - "failed to start tool 'memcheck' >> for platform x86-linux" no such file or directory". I can see >> memcheck-x86-linux file under lib, but it keeps reporting everytime. >> >> copied all lib and bin files which are generated after I compiled >> valgrind package, when I run my exe with valgrind, I am getting above >> error, any idea? >> > > You need to put files the same directory on the target machine that they > were in on the build machine (probably /usr/lib/valgrind) or valgrind won't > find them. > > Tom > > -- > Tom Hughes (to...@co...) > http://www.compton.nu/ > |
|
From: Tom H. <to...@co...> - 2010-01-15 22:14:11
|
On 15/01/10 21:05, Vasanta wrote: > Thanks Tom. When I compile, I gets some binaries in bin directory and > some so files and scripts in lib directory, I copied all those images > onto target, also my path looks correct, but I always gets same error > "memcheck". You need to do "make install" to install it - that will show you where the files need to go. Then copy them over to the target system in the same locations. Broadly speaking however the lib files need to go in /usr/lib/valgrind as I explained in my previous message. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Vasanta <vt...@gm...> - 2010-01-17 15:14:41
|
Thanks Tom, appreciated. I just compiled and installed on x86 Linux machine, it installs in /usr/local/bin and /usr/local/lib directories, also it copies header files into /usr/local/include directory, it works orefectly. But I have embedded target which is also x86 based, I cannot run "make install" on that target since I compiles everything on x86 Host and create one large image and burn that image onto target, only way is, I can created a tar ball and copy that onto target and untar all those files back on target, makesure it went into respective directories, I think mainly I need /usr/local/bin and /uselocal/lib. Let me try. Thanks, On Fri, Jan 15, 2010 at 5:14 PM, Tom Hughes <to...@co...> wrote: > On 15/01/10 21:05, Vasanta wrote: > >> Thanks Tom. When I compile, I gets some binaries in bin directory and >> some so files and scripts in lib directory, I copied all those images >> onto target, also my path looks correct, but I always gets same error >> "memcheck". >> > > You need to do "make install" to install it - that will show you where the > files need to go. Then copy them over to the target system in the same > locations. > > Broadly speaking however the lib files need to go in /usr/lib/valgrind as I > explained in my previous message. > > > Tom > > -- > Tom Hughes (to...@co...) > http://www.compton.nu/ > |
|
From: Vasanta <vt...@gm...> - 2010-01-18 14:27:09
|
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?. On Sun, Jan 17, 2010 at 10:14 AM, Vasanta <vt...@gm...> wrote: > Thanks Tom, appreciated. > > I just compiled and installed on x86 Linux machine, it installs in > /usr/local/bin and /usr/local/lib directories, also it copies header files > into /usr/local/include directory, it works orefectly. But I have embedded > target which is also x86 based, I cannot run "make install" on that target > since I compiles everything on x86 Host and create one large image and burn > that image onto target, only way is, I can created a tar ball and copy that > onto target and untar all those files back on target, makesure it went into > respective directories, I think mainly I need /usr/local/bin and > /uselocal/lib. Let me try. > > Thanks, > > > > > > > > On Fri, Jan 15, 2010 at 5:14 PM, Tom Hughes <to...@co...> wrote: > >> On 15/01/10 21:05, Vasanta wrote: >> >>> Thanks Tom. When I compile, I gets some binaries in bin directory and >>> some so files and scripts in lib directory, I copied all those images >>> onto target, also my path looks correct, but I always gets same error >>> "memcheck". >>> >> >> You need to do "make install" to install it - that will show you where the >> files need to go. Then copy them over to the target system in the same >> locations. >> >> Broadly speaking however the lib files need to go in /usr/lib/valgrind as >> I explained in my previous message. >> >> >> Tom >> >> -- >> Tom Hughes (to...@co...) >> http://www.compton.nu/ >> > > |
|
From: Tom H. <to...@co...> - 2010-01-18 14:32:34
|
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. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Vasanta <vt...@gm...> - 2010-01-18 14:49:27
|
I did copied into right place, why still pointing same error?.
#
# ls /usr/local/lib/valgrind/
cachegrind-x86-linux memcheck-x86-linux
callgrind-x86-linux none-x86-linux
default.supp vgpreload_core-x86-linux.so
drd-x86-linux vgpreload_drd-x86-linux.so
exp-bbv-x86-linux vgpreload_exp-ptrcheck-x86-linux.so
exp-ptrcheck-x86-linux vgpreload_helgrind-x86-linux.so
helgrind-x86-linux vgpreload_massif-x86-linux.so
lackey-x86-linux vgpreload_memcheck-x86-linux.so
massif-x86-linux
# ls -l /usr/local/lib/valgrind/
-rwxr-xr-x 1 0 0 4636305 cachegrind-x86-linux
-rwxr-xr-x 1 0 0 4891451 callgrind-x86-linux
-rw-r--r-- 1 0 0 27934 default.supp
-rwxr-xr-x 1 0 0 4857510 drd-x86-linux
-rwxr-xr-x 1 0 0 4519362 exp-bbv-x86-linux
-rwxr-xr-x 1 0 0 4729657 exp-ptrcheck-x86-linux
-rwxr-xr-x 1 0 0 4837460 helgrind-x86-linux
-rwxr-xr-x 1 0 0 4529944 lackey-x86-linux
-rwxr-xr-x 1 0 0 4568883 massif-x86-linux
-rwxr-xr-x 1 0 0 5040139 memcheck-x86-linux
-rwxr-xr-x 1 0 0 4509675 none-x86-linux
-rwxr-xr-x 1 0 0 6765 vgpreload_core-x86-linux.so
-rwxr-xr-x 1 0 0 170657 vgpreload_drd-x86-linux.so
-rwxr-xr-x 1 0 0 45354
vgpreload_exp-ptrcheck-x86-linux.so
-rwxr-xr-x 1 0 0 107935 vgpreload_helgrind-x86-linux.so
-rwxr-xr-x 1 0 0 37223 vgpreload_massif-x86-linux.so
-rwxr-xr-x 1 0 0 72136 vgpreload_memcheck-x86-linux.so
#
# ls -l /usr/local/lib/pkgconfig/valgrind.pc
-rw-r--r-- 1 0 0 379
/usr/local/lib/pkgconfig/valgrind.pc
#
# ls -l /usr/local/bin/
-rwxr-xr-x 1 0 0 40959 callgrind_annotate
-rwxr-xr-x 1 0 0 13662 callgrind_control
-rwxr-xr-x 1 0 0 32064 cg_annotate
-rwxr-xr-x 1 0 0 42942 cg_merge
-rwxr-xr-x 1 0 0 24211 ms_print
-rwxr-xr-x 1 0 0 8531 no_op_client_for_valgrind
-rwxr-xr-x 1 0 0 30823 valgrind
-rwxr-xr-x 1 0 0 18887 valgrind-listener
# cat /usr/local/lib/pkgconfig/valgrind.pc
prefix=/home/netgard/comps/valgrind/install
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include/valgrind
arch=x86
os=linux
platform=x86-linux
valt_load_address=0x38000000
Name: Valgrind
Description: A dynamic binary instrumentation framework
Version: 3.5.0
Requires:
Libs: -L${libdir}/valgrind/x86-linux -lcoregrind -lvex -lgcc
Cflags: -I${includedir}
#
#
# valgrind
valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such
file or directory
#
#
On Mon, Jan 18, 2010 at 9:32 AM, Tom Hughes <to...@co...> 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.
>
>
> Tom
>
> --
> Tom Hughes (to...@co...)
> http://www.compton.nu/
>
|
|
From: Tom H. <to...@co...> - 2010-01-18 15:05:17
|
On 18/01/10 14:49, Vasanta wrote: > I did copied into right place, why still pointing same error?. Run it with "-d" and it will tell you the full path of the tool it is trying to start. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Ashley P. <as...@pi...> - 2010-01-18 15:07:58
|
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, |
|
From: Vasanta <vt...@gm...> - 2010-01-18 15:47:33
|
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?. On Mon, Jan 18, 2010 at 10:07 AM, Ashley Pittman <as...@pi...>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 > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Ashley P. <as...@pi...> - 2010-01-18 16:13:11
|
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 <as...@pi...> 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 > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Vasanta <vt...@gm...> - 2010-01-18 16:30:31
|
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. 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 <as...@pi...>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 <as...@pi...>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 >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users >> > > > |
|
From: Ashley P. <as...@pi...> - 2010-01-18 16:49:02
|
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 <as...@pi...> 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 <as...@pi...> 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 >> Val...@li... >> 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 > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Vasanta <vt...@gm...> - 2010-01-18 16:59:25
|
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 <as...@pi...>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 <as...@pi...>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 <as...@pi...>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 >>> Val...@li... >>> 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 > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > |
|
From: Vasanta <vt...@gm...> - 2010-01-18 20:24:11
|
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 <vt...@gm...> 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 <as...@pi...>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 <as...@pi...>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 <as...@pi...>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 >>>> Val...@li... >>>> 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 >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users >> >> >> > |
|
From: Ashley P. <as...@pi...> - 2010-01-18 21:34:24
|
On 18 Jan 2010, at 21:06, Vasanta wrote: > Thanks Ashley. > > I can see lot of places function called "adpModuleDebug", it shows address, Is there anyway valgrind can point little bit inside where exactly (line number like gdb) memory leak is?. any idea?. For this the code needs to be compiled with debugging enabled, the same as with gdb. Ensure you are using the -g option to the compiler. > Ashley. |
|
From: Ashley P. <as...@pi...> - 2010-01-19 14:27:53
|
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 >> > |
|
From: Vasanta <vt...@gm...> - 2010-01-19 19:27:32
|
this is the code which calls sendto - I added memset before init variables
at line 3, didn't help.
1. UMI_REQ_INFO * pUmiReq;
2. unsigned int reqBufSize;
3.
4.
5. pUmiReq = (UMI_REQ_INFO *)pBuf;
6. pUmiReq->cmd = cmd;
7. pUmiReq->srcId = pSrcCtx->myId;
8. pUmiReq->reqOpt = reqOpt;
9. pUmiReq->reqId = reqId;
10. pUmiReq->req = 1;
11.
12. if (sendto (pSrcCtx->sockFd, pUmiReq, reqBufSize,
13. 0, (struct sockaddr *) &destId,
sizeof(UMI_COMP_ID)) == -1)
14. {
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
>>
>>
>
>
|
|
From: Ron E. <ron...@gm...> - 2010-01-19 16:24:18
|
Hi There, I have troubles compiling valgrind for my target system. It keeps hanging on following: ../coregrind/libcoregrind-x86-linux.a(libcoregrind_x86_linux_a-aspacemgr- linux.o): In function `vgPlain_am_do_sync_check': m_aspacemgr/aspacemgr-linux.c:1059: undefined reference to `parse_procselfmaps' ../coregrind/libcoregrind-x86-linux.a(libcoregrind_x86_linux_a-aspacemgr- linux.o): In function `vgPlain_am_startup': m_aspacemgr/aspacemgr-linux.c:1683: undefined reference to `parse_procselfmaps' collect2: ld returned 1 exit status make[4]: *** [memcheck-x86-linux] Error 1 make[4]: Leaving directory `/home/ron/valgrind-3.5.0/memcheck' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/ron/valgrind-3.5.0/memcheck' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/ron/valgrind-3.5.0/memcheck' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/ron/valgrind-3.5.0' make: *** [all] Error 2 [root@DEVNEMS valgrind-3.5.0]# I tried "./configure --enable-only32bit --enable-inner" Does anyone know how i can get it compiled successfully? Thanks! Ron |
|
From: Vasanta <vt...@gm...> - 2010-01-20 15:47:08
|
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.
>
>
> 1. UMI_REQ_INFO * pUmiReq;
> 2. unsigned int reqBufSize;
> 3.
> 4.
> 5. pUmiReq = (UMI_REQ_INFO *)pBuf;
> 6. pUmiReq->cmd = cmd;
> 7. pUmiReq->srcId = pSrcCtx->myId;
> 8. pUmiReq->reqOpt = reqOpt;
> 9. pUmiReq->reqId = reqId;
> 10. pUmiReq->req = 1;
> 11.
> 12. if (sendto (pSrcCtx->sockFd, pUmiReq, reqBufSize,
> 13. 0, (struct sockaddr *) &destId, sizeof(UMI_COMP_ID)) == -1)
>
> 14. {
>
>
>
> 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
>>>
>>>
>>
>>
>
|
|
From: Brian T. C. <cr...@fi...> - 2010-01-20 16:41:13
|
On 1/20/2010 7:46 AM, Vasanta wrote: > google says "Uninitilised data" with valgrind tool is Ok, there is no > harm with that at all. Google is mistaken. Uninitialized data errors from valgrind can be very serious (crash or compromise serious) issues in your program that you very much ought to fix. -- Brian |
|
From: Ashley P. <as...@pi...> - 2010-01-20 16:49:00
|
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
>>>
>>
>
>
>
|
|
From: Tom H. <to...@co...> - 2010-01-20 17:07:18
|
On 20/01/10 16:48, Ashley Pittman wrote:
>
> 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.
From "man pcscd":
-f, --foreground
Runs pcscd in the foreground and sends log messages
to stderr instead of syslog(3).
Which should do what is needed.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Vasanta <vt...@gm...> - 2010-01-20 18:34:45
|
Ashely / Tom: Initially this pcscd runs, then it forks, that is why PID is diff, I run with trace-children=yes, didn't get much info since program is keep running, I don't know how can I forcefully exit, the main function in this below link for pcscdaemon.c file. also I tried --foreground, gives error for that option. any idea can I force exit pcscd? http://www.opensource.apple.com/source/SmartCardServices/SmartCardServices-10/src/pcscdaemon.c On Wed, Jan 20, 2010 at 11:48 AM, Ashley Pittman <as...@pi...>wrote: > > 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. >> >> >> 1. UMI_REQ_INFO * pUmiReq; >> 2. unsigned int reqBufSize; >> 3. >> 4. >> 5. pUmiReq = (UMI_REQ_INFO *)pBuf; >> 6. pUmiReq->cmd = cmd; >> 7. pUmiReq->srcId = pSrcCtx->myId; >> 8. pUmiReq->reqOpt = reqOpt; >> 9. pUmiReq->reqId = reqId; >> 10. pUmiReq->req = 1; >> 11. >> 12. if (sendto (pSrcCtx->sockFd, pUmiReq, reqBufSize, >> 13. 0, (struct sockaddr *) &destId, sizeof(UMI_COMP_ID)) == -1) >> >> 14. { >> >> >> >> 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 >>>> >>>> >>> >>> >> > > |