Re: Timer delete

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users