RFC: more robust handling of terminated but still attached threads

[Florian Weimer]

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?

Thanks,
Florian