|
From: Bart V. A. <bar...@gm...> - 2006-12-01 10:15:48
|
When I use Valgrind 3.2.1 on a device MontaVista Linux 4.0, Valgrind
complains on POSIX thread calls while these messages should have been
suppressed via the default suppression file. Is this because the
libraries on the device do not have debug information ? Is valgrind
able to read debug info from separate files (/mnt/usr/lib/.../*.debug)
?
>From /mnt/usr/lib/valgrind/default.supp:
...
{
LinuxThreads: write/pthread_create
Memcheck:Param
write(buf)
fun:pthread_create@@GLIBC_2.1
}
...
>From Valgrind's output:
==3819== Memcheck, a memory error detector.
==3819== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==3819== Using LibVEX rev 1658, a library for dynamic binary translation.
==3819== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==3819== Using valgrind-3.2.1, a dynamic binary instrumentation framework.
==3819== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==3819==
--3819-- Command line
--3819-- ./DCM_IO
--3819-- Startup, with flags:
--3819-- --num-callers=32
--3819-- --error-limit=no
--3819-- --suppressions=/home/vanassb/Trunk/DCM_MB/TRFS-mvl40/RFS-440/app/bin
/dcm-suppressions.txt
--3819-- -v
--3819-- Contents of /proc/version:
--3819-- Linux version 2.6.10-mV01-00-13 (build@sabekorlnx03) (gcc version 3.4
.3 (MontaVista 3.4.3-25.0.107.0601076 2006-07-21)) #1 Thu Nov 30 18:49:47 CET 20
06
--3819-- Arch and hwcaps: PPC32, ppc32-int
...
--3819-- Reading syms from /lib/libpthread-0.10.so (0xFF48000)
--3819-- object doesn't have a symbol table
...
==3819== Syscall param write(buf) points to uninitialised byte(s)
==3819== at 0xFF508B4: pthread_create (in /lib/libpthread-0.10.so)
==3819== by 0x1011D4C0: GenOsSpawnTask (GenOsTask_Linux.cpp:538)
==3819== by 0x1008C860: FtimerInitDataTask (ftimer.c:570)
==3819== by 0x103F3CE8: CRoot::CRoot(int, MuxCore::enuBoardType, bool, unsign
ed long, CIP_Address, std::string const&) (Root.cpp:182)
==3819== by 0x10006BD4: main (DCM_IO.cpp:139)
==3819== Address 0x7EFFD64C is on thread 1's stack
...
|
|
From: Julian S. <js...@ac...> - 2006-12-01 15:44:01
|
On Friday 01 December 2006 10:15, Bart Van Assche wrote:
> When I use Valgrind 3.2.1 on a device MontaVista Linux 4.0, Valgrind
> complains on POSIX thread calls while these messages should have been
> suppressed via the default suppression file. Is this because the
> libraries on the device do not have debug information ?
No - the suppression mechanism only uses function names and shared
object names to identify functions, so it should work.
> Is valgrind
> able to read debug info from separate files (/mnt/usr/lib/.../*.debug)
> ?
yes.
> ...
> {
> LinuxThreads: write/pthread_create
> Memcheck:Param
> write(buf)
> fun:pthread_create@@GLIBC_2.1
> }
> ...
> ==3819== Syscall param write(buf) points to uninitialised byte(s)
> ==3819== at 0xFF508B4: pthread_create (in /lib/libpthread-0.10.so)
> ==3819== by 0x1011D4C0: GenOsSpawnTask (GenOsTask_Linux.cpp:538)
> ==3819== by 0x1008C860: FtimerInitDataTask (ftimer.c:570)
> ==3819== by 0x103F3CE8: CRoot::CRoot(int, MuxCore::enuBoardType, bool,
> unsign ed long, CIP_Address, std::string const&) (Root.cpp:182)
> ==3819== by 0x10006BD4: main (DCM_IO.cpp:139)
> ==3819== Address 0x7EFFD64C is on thread 1's stack
Hmm. That's odd. Usually the easiest and most reliable way to create
suppressions is to use --gen-suppressions=all. Did you do that, or
create this one by hand?
I have to say the suppression looks like it _should_ suppress the error,
though.
J
|
|
From: Bart V. A. <bar...@gm...> - 2006-12-01 16:00:39
|
Hello Julian,
I tried both: using the default suppressions and adding the
suppression suggested by Valgrind to a custom suppressions file. Is
there something more I can try ? Can I let Valgrind generate more
debug info about suppressions ? Should I make a system available
online ?
On 12/1/06, Julian Seward <js...@ac...> wrote:
> On Friday 01 December 2006 10:15, Bart Van Assche wrote:
> > When I use Valgrind 3.2.1 on a device MontaVista Linux 4.0, Valgrind
> > complains on POSIX thread calls while these messages should have been
> > suppressed via the default suppression file. Is this because the
> > libraries on the device do not have debug information ?
>
> No - the suppression mechanism only uses function names and shared
> object names to identify functions, so it should work.
>
> > Is valgrind
> > able to read debug info from separate files (/mnt/usr/lib/.../*.debug)
> > ?
>
> yes.
>
> > ...
> > {
> > LinuxThreads: write/pthread_create
> > Memcheck:Param
> > write(buf)
> > fun:pthread_create@@GLIBC_2.1
> > }
> > ...
> > ==3819== Syscall param write(buf) points to uninitialised byte(s)
> > ==3819== at 0xFF508B4: pthread_create (in /lib/libpthread-0.10.so)
> > ==3819== by 0x1011D4C0: GenOsSpawnTask (GenOsTask_Linux.cpp:538)
> > ==3819== by 0x1008C860: FtimerInitDataTask (ftimer.c:570)
> > ==3819== by 0x103F3CE8: CRoot::CRoot(int, MuxCore::enuBoardType, bool,
> > unsign ed long, CIP_Address, std::string const&) (Root.cpp:182)
> > ==3819== by 0x10006BD4: main (DCM_IO.cpp:139)
> > ==3819== Address 0x7EFFD64C is on thread 1's stack
>
> Hmm. That's odd. Usually the easiest and most reliable way to create
> suppressions is to use --gen-suppressions=all. Did you do that, or
> create this one by hand?
>
> I have to say the suppression looks like it _should_ suppress the error,
> though.
|
|
From: Julian S. <js...@ac...> - 2006-12-01 16:05:22
|
Does it help to remove "@@GLIBC_2.1" from the suppression?
J
On Friday 01 December 2006 16:00, Bart Van Assche wrote:
> Hello Julian,
>
> I tried both: using the default suppressions and adding the
> suppression suggested by Valgrind to a custom suppressions file. Is
> there something more I can try ? Can I let Valgrind generate more
> debug info about suppressions ? Should I make a system available
> online ?
>
> On 12/1/06, Julian Seward <js...@ac...> wrote:
> > On Friday 01 December 2006 10:15, Bart Van Assche wrote:
> > > When I use Valgrind 3.2.1 on a device MontaVista Linux 4.0, Valgrind
> > > complains on POSIX thread calls while these messages should have been
> > > suppressed via the default suppression file. Is this because the
> > > libraries on the device do not have debug information ?
> >
> > No - the suppression mechanism only uses function names and shared
> > object names to identify functions, so it should work.
> >
> > > Is valgrind
> > > able to read debug info from separate files (/mnt/usr/lib/.../*.debug)
> > > ?
> >
> > yes.
> >
> > > ...
> > > {
> > > LinuxThreads: write/pthread_create
> > > Memcheck:Param
> > > write(buf)
> > > fun:pthread_create@@GLIBC_2.1
> > > }
> > > ...
> > > ==3819== Syscall param write(buf) points to uninitialised byte(s)
> > > ==3819== at 0xFF508B4: pthread_create (in /lib/libpthread-0.10.so)
> > > ==3819== by 0x1011D4C0: GenOsSpawnTask (GenOsTask_Linux.cpp:538)
> > > ==3819== by 0x1008C860: FtimerInitDataTask (ftimer.c:570)
> > > ==3819== by 0x103F3CE8: CRoot::CRoot(int, MuxCore::enuBoardType,
> > > bool, unsign ed long, CIP_Address, std::string const&) (Root.cpp:182)
> > > ==3819== by 0x10006BD4: main (DCM_IO.cpp:139)
> > > ==3819== Address 0x7EFFD64C is on thread 1's stack
> >
> > Hmm. That's odd. Usually the easiest and most reliable way to create
> > suppressions is to use --gen-suppressions=all. Did you do that, or
> > create this one by hand?
> >
> > I have to say the suppression looks like it _should_ suppress the error,
> > though.
|
|
From: Bart V. A. <bar...@gm...> - 2006-12-01 16:11:35
|
Sorry, but that didn't help: this is the suppression that I had added
to my suppresion file, based on the output of --gen-suppressions=yes:
{
pthread-create-1
Memcheck:Param
write(buf)
obj:/lib/libpthread-0.10.so
fun:pthread_create
}
On 12/1/06, Julian Seward <js...@ac...> wrote:
>
> Does it help to remove "@@GLIBC_2.1" from the suppression?
>
> J
|
|
From: Nicholas N. <nj...@cs...> - 2006-12-01 22:21:22
|
On Fri, 1 Dec 2006, Julian Seward wrote: > > Does it help to remove "@@GLIBC_2.1" from the suppression? Or using "fun:pthread_create*" might help? Nick |