Re: RFR: 8232839: JDI AfterThreadDeathTest.java failed due to "FAILED: Did not get expected IllegalThreadStateException on a StepRequest.enable()"
On Wed, 7 Jun 2023 23:17:18 GMT, Chris Plummer 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.
thanks for the reviews Kevin and Serguei!
-
PR Comment: https://git.openjdk.org/jdk/pull/14372#issuecomment-1584951868
Re: RFR: 8232839: JDI AfterThreadDeathTest.java failed due to "FAILED: Did not get expected IllegalThreadStateException on a StepRequest.enable()"
On Wed, 7 Jun 2023 23:17:18 GMT, Chris Plummer 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
Re: RFR: 8232839: JDI AfterThreadDeathTest.java failed due to "FAILED: Did not get expected IllegalThreadStateException on a StepRequest.enable()"
On Wed, 7 Jun 2023 23:17:18 GMT, Chris Plummer 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.
It looks good.
Thanks,
Serguei
-
Marked as reviewed by sspitsyn (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/14372#pullrequestreview-1468978228
RFR: 8232839: JDI AfterThreadDeathTest.java failed due to "FAILED: Did not get expected IllegalThreadStateException on a StepRequest.enable()"
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.
-
Commit messages:
- Fix 8232839
Changes: https://git.openjdk.org/jdk/pull/14372/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14372&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8232839
Stats: 24 lines in 2 files changed: 11 ins; 3 del; 10 mod
Patch: https://git.openjdk.org/jdk/pull/14372.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/14372/head:pull/14372
PR: https://git.openjdk.org/jdk/pull/14372
