|
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.
|