RFR: 8232839: JDI AfterThreadDeathTest.java failed due to "FAILED: Did not get expected IllegalThreadStateException on a StepRequest.enable()"

Kevin Walls kevinw at openjdk.org
Thu Jun 8 19:36:43 UTC 2023


On Wed, 7 Jun 2023 23:17:18 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test waits for a ThreadDeathEvent for "main". Once that arrives, it then waits for the next ThreadStartEvent (for any thread). Once it arrives, the test tries to create and enable a StepRequest on the "main" thread. Since "main" is supposedly dead, the expectation is an IllegalThreadStateException. However, it turns out that sometimes the enabling can in fact succeed.
> 
> Just because a ThreadDeathEvent has been received for a thread does not mean you can no longer do things with the thread like suspend it or enable a StepEvent. There is a short delay in the debug agent after sending the ThreadDeathEvent before it stops tracking the thread. The thread can still be acted upon until then. The JDWP and JDI specs seem to support doing this:
> 
>> Notification of a completed thread in the target VM. The notification is generated by the dying thread before it terminates. Because of this timing, it is possible for {@link VirtualMachine#allThreads} to return this thread after this event is received.
>> 
>> Note that this event gives no information about the lifetime of the thread object. It may or may not be collected soon depending on what references exist in the target VM.
> 
> What this means is that when the test receives some arbitrary ThreadStartEvent after the "main" ThreadDeathEvent has been received, the test may in fact still be able to enable a StepRequest on the "main" thread, causing the test to fail. What seems to trigger the failure is receiving an unexpected spurious ThreadStartEvent such as from the Common-Clean thread or a carrier thread, although even then it only fails some of the time. In fact if I modify the test to enable the StepRequest when it receives the ThreadDeathEvent for "main", it still almost always passes, but will fail more frequently than it normally does.
> 
> It seems if the test always waits for the ThreadStartEvent for "DestroyJavaVM", then the "main" thread is truly gone by then and the test always passes, so this is how I've chosen to fix the issue.
> 
> Tested with tier1, tier2 svc tests, and tier5 svc tests.

I think it makes sense!

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

Marked as reviewed by kevinw (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14372#pullrequestreview-1470630717


More information about the serviceability-dev mailing list