RFC: more robust handling of terminated but still attached threads

Florian Weimer fweimer at redhat.com
Tue Jul 3 11:28:49 UTC 2018

On 07/03/2018 11:21 AM, David Holmes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8205878
> We hit asserts or trigger SEGVs when we try to operate on a native 
> thread ID for a JNI-attached thread that has actually terminated but 
> which did not detach first. It still appears in the threadsList and we 
> try to process it during DumpOnExit (but there are probably other 
> operations that could run into this in the general case).

This bug is not public.

The use case isn't entirely clear to me.  If you are sufficiently 
unlucky, the memory behind a pthread_t value is simply gone after thread 
exit (and potentially TCB/thread stack reclamation in the thread 
library).  On glibc, this includes the internal TID, which is required 
for pthread_kill (thr, 0) actually sending the signal.

I'm not familiar with the Hotspot run-time and why it needs to do this. 
Can you deregister the thread from a thread directory once it exits 
(using one of the TLS variants with a destructor)?  Or is the concern 
there that the destructor would not run late enough?


More information about the hotspot-runtime-dev mailing list