RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException

David Holmes dholmes at openjdk.org
Fri Jul 18 03:22:53 UTC 2025


On Thu, 17 Jul 2025 16:35:11 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> But maybe we could also add a has_async_exception_condition() check to bailout.

Yes.

BTW I don't think this is in any way new. I think Thread.stop would have had the same issue. Issuing the internal interrupt was just a convenient way to unblock all the interruptible blocking points - and as Alan notes, monitor acquisition is not interruptible. We likely did not care that this could make the interrupt state appear odd if the thread continued after the async (ThreadDeath) exception. Not sure it is really that different for the debugger - if we have stopped the thread (not just suspended it) then we shouldn't really be expecting it to continue as normal afterwards.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3085431826


More information about the serviceability-dev mailing list