RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException
David Holmes
dholmes at openjdk.org
Thu Jul 17 12:15:50 UTC 2025
On Thu, 17 Jul 2025 10:12:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
> If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`.
>
> The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`.
>
> There are a couple of concerns with this fix which would be nice to sort out with reviewers:
> 1. The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue)
> 2. The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess`
>
> I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`.
>
> The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it.
>
> Testing:
> - Mach5 tiers 1-6 are passed
> - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest`
I need to dive into the code tomorrow but I can't help think that doing an actual interrupt is not really what is needed, we just need to unpark the thread if it is blocked ...
-------------
PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3083837302
More information about the serviceability-dev
mailing list