On 11/12/22 01:46, John Reiser wrote:
It's a bug (or implementation constraint) in glibc timer.
When I run it under valgrind-3.19.0 with glibc-debuginfo and
glibc-debugsource installed (2.35-17.fc36.x86_64):
[Notice the annotation "LOOK HERE"]
==281161== Command: ./a.out
==281161==
--281161:0: sched WARNING: pthread stack cache cannot be disabled!
<<<<< LOOK HERE <<<<<
And also
Philiipe wrote:
Possibly --sim-hints=no-nptl-pthread-stackcache might help (if I
re-read the manual entry for this sim-hint).
As the manpage says, the pthread stackcache stuff is mainly for Helgrind.
What the code does is use debuginfo to find the GNU libc variable that
describes the size of the stack cache, and forces it to be some large
value. That causes libthead to think that the cache is full (when it is
still really empty) and not use the cache. That means that every time a
thread gets created a new stack will get allocated rather than allocated
and recycled in the cache.
The caching causes problems with Helgrind for applications using thread
local storage in sequences like
write to TLS var on thread 2
thread 2 exit
thread 3 created recycles thread2's TLS
read from TLS var on thread 3
Helgrind just sees unprotected reads and writes from the same address
without knowing that it isn't the same variable.
This test is currently failing for me (Fedora 36 amd64):
paulf> perl tests/vg_regtest helgrind/tests/tls_threads
tls_threads: valgrind -q --sim-hints=no-nptl-pthread-stackcache
./tls_threads
*** tls_threads failed (stderr) ***
(More details here
https://github.com/paulfloyd/freebsd_valgrind/issues/113 since I've
looked into how to implement something similar for FreeBSD).
I don't see how this would affect a leak though.
I did some tests to check that __libc_freeres is being called (and it is
being called).
So my conclusion is that there are two problems
1. Some cleanup code missing in __libc_freeres that is causing this leak
(libc problem)
2. no-stackcache not working. This is more a Valgrind problem, but it
does rely on twiddling libc internals, so it's not too surprising that
it breaks. That needs work on the Valgrind side.
FWIW on FreeBSD (no stack cache disable or libc freeres) I also get a
bunch of leaks that I need to suppress.
A+
Paul
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
