On Sat, 2022-11-12 at 12:21 +0100, Paul Floyd wrote:

> 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.
....


> 
> I don't see how this would affect a leak though.

This sim-hint also influences memcheck behaviour related to __thread (i.e. tls) 
variables.
Here is the extract of the doc:
"When using the memcheck tool, disabling the cache ensures the memory used by 
glibc to 
handle __thread variables is directly released when a thread terminates."
(at least that was likely true in 2014, when the above was written).


> 
> 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.
Yes, the cache disabling is quite hacky, as mentionnd in the doc:
"Valgrind disables the cache using some internal
 knowledge of the glibc stack cache implementation and by
 examining the debug information of the pthread
 library. This technique is thus somewhat fragile and might
 not work for all glibc versions. This has been successfully
 tested with various glibc versions (e.g. 2.11, 2.16, 2.18)
 on various platforms."



As you indicate, it looks broken on the more recent glibc version you tried.

Philippe



_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Reply via email to