|
From: Bart V. A. <bar...@gm...> - 2008-05-04 12:00:23
|
On Sun, May 4, 2008 at 11:26 AM, Julian Seward <js...@ac...> wrote: > >> As you know on Linux the NPTL allocates space on the top of the stack >> for NPTL-private data. This data is accessed by more than one thread. >> In order to avoid false positives on this NPTL-private data I let DRD >> suppress data race reports on data accesses in the NPTL-private data >> area. > > What happens if NPTL puts some thread private data in some other > place? Then DRD complains again. I saw the same problem in > Helgrind but simply decided to suppress all errors that it > reports inside libpthread. One of the design goals of the NPTL was to make the creation of new threads as fast as possible. That is why the NPTL puts thread-private data on thread stacks instead of allocating these via a separate memory allocation. Any other approach would make the NPTL slightly slower. With regard to future NPTL versions: the approach to suppress all errors in libpthread is not future-proof. If some day some of the NPTL-functions that access thread-private data are implemented as inline functions, suppressing data races on the basis of call stack pattern matching won't work anymore. > nframes = 6 > sps[0] = 0xFEA04790 > sps[1] = 0xFEA048D0 > sps[2] = 0xFEA048E0 > sps[3] = 0xFEA04910 > sps[4] = 0xFEA04940 > sps[5] = 0x0 > sps[6] = 0x0 > sps[7] = 0x0 > sps[8] = 0x46AAD70 > sps[9] = 0xFFFFFFFF Thanks for the workaround -- by this time I have checked in a slightly modified variant of the workaround. But the above output confirms that VG_(get_StackTrace)() returns values in sps[] that are not valid stack pointers for the relevant thread. I did not expect this this behavior from VG_(get_StackTrace)(). If this is the intended behavior of VG_(get_StackTrace)(), can you please document this behavior ? Bart. |