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?
Thanks,
Florian
More information about the hotspot-runtime-dev
mailing list