This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

pthread stack cache and valgrind helgrind false positive race error on tls variables


Hello,

Valgrind helgrind tool reports false positive race condition errors on
tls variables, on some stack addresses, and on some internal glibc tls
related data structures.

These false positives are due to the cache implemented in
allocatestack.c:
helgrind race condition detection algorithm is based on the observation
of pthread synchronisation primitives (e.g. pthread_mutex_lock).
helgrind does not know about the internal low level synchronisation
primitives of pthread lib (and even if it would know about, observing
them is not possible since these primitives are inlined and/or macros).

I have implemented a change in valgrind helgrind to disable the
cache: when the pthread lib is loaded, valgrind searches for the
data symbol "stack_cache_actsize" and stores a huge value at this
address. Then no stack is ever added to the cache.
This has been tested on x86 (glibc2.11), amd64 (glibc2.11)
and ppc64 (glibc 2.16).
This seems to work but is a nasty/fragile hack, depending
on allocatestack.c internal variable and code.

Is there a better way to disable the stack cache ?
(I have not found one by reading the code of glibc 2.17).

What kind of changes could be implemented in a future glibc to
have a better way to disable (or configure) the stack cache size ?
Maybe something like
   export PTHREAD_STACK_CACHE_MAX_SIZE=....
(and setting it to 0 would then disable the cache).

Thanks

Philippe

NB: I can provide a small test program causing helgrind false positive
on tls variable if you deem it useful.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]