Also spent many a blurry eyed hour chasing false positives. Yet to stumble into one that was actually a valid gripe against Pth (and you can't really blame valgrind :). So your best bet may be to just "roll over" on Pth internals by using a supression file something like the following (obj: being where ever you Pth so resides);

Later - Jay

## Pth specific (basically everything :()
{
   libpth-Addr4-internal
   Memcheck:Addr4
   obj:/opt/gcc3/lib/libpth.so.20.0.20
}
{
   libpth-Value4-internal
   Memcheck:Value4
   obj:/opt/gcc3/lib/libpth.so.20.0.20
}
{
   libpth-Cond-internal
   Memcheck:Cond
   obj:/opt/gcc3/lib/libpth.so.20.0.20
}

## Pth system call related
{
   swapcontext-Value4
   Memcheck:Value4
   fun:swapcontext
}
{
   swapcontext-Addr4
   Memcheck:Addr4
   fun:swapcontext
}
{
   swapcontext-Cond
   Memcheck:Cond
   fun:swapcontext
}
{
   sigismember-Value4
   Memcheck:Value4
   fun:sigismember
}
{
   sigismember-Addr4
   Memcheck:Addr4
   fun:sigismember
}
{
   sigismember-Cond
   Memcheck:Cond
   fun:sigismember
}


Ralf S. Engelschall wrote:
On Tue, Aug 10, 2004, Robert Anderson wrote:

  
[...]
This program compiles and runs with the expected behavior.
However, valgrind (http://valgrind.kde.org/) complains about
numerous memory access errors.  I am not certain if these are
real or false positives.

Here's an example.  After calling the first pth_yield(t), it
complains about invalid memory reads:

==2775== Invalid read of size 4
==2775==    at 0x3C153BA1: swapcontext (in /lib/tls/libc-2.3.2.so)
==2775==  Address 0x3C25E314 is 256 bytes inside a block of size
760 alloc'd
==2775==    at 0x3C01E338: malloc (vg_replace_malloc.c:105)
==2775==    by 0x3C0267B9: __pth_tcb_alloc (in
/g/g10/rwa/redhat-packages/pth-1.4.1/lib/libpth.so.14.0.21)
==2775==    by 0x3C02993A: pth_spawn (in
/g/g10/rwa/redhat-packages/pth-1.4.1/lib/libpth.so.14.0.21)
==2775==    by 0x8049985: main (minimal.C:20)

Is there an error in my program?  Or does this look like some
kind of false positive?
    

Well, GNU Pth here seems to just call malloc(3) here and
internally this fails, right? I think there is either
a bug in GNU glibc 2.3.2 or valgrind is false here.

                                       Ralf S. Engelschall
                                       [EMAIL PROTECTED]
                                       www.engelschall.com

______________________________________________________________________
GNU Portable Threads (Pth)            http://www.gnu.org/software/pth/
Development Site                      http://www.ossp.org/pkg/lib/pth/
Distribution Files                          ftp://ftp.gnu.org/gnu/pth/
Distribution Snapshots                 ftp://ftp.ossp.org/pkg/lib/pth/
User Support Mailing List                            [EMAIL PROTECTED]
Automated List Manager (Majordomo)           [EMAIL PROTECTED]


  

Reply via email to