-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8307968: serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java timed out #13969
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
👋 Welcome back sspitsyn! A progress list of the required criteria for merging this PR into |
Webrevs
|
} | ||
if (!seenExceptionFromA) { | ||
StopThreadTest.setFailed("TestTask.run: expected AssertionError from method A()"); | ||
} | ||
Thread.interrupted(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure why this was move down this far. It seems you would want to do this before the StopThreadTest.setFailed()
call just to be extra safe, so that means move it before the if
statement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good suggestion. Fixed.
@@ -248,6 +240,7 @@ public void run() { | |||
// - when suspended: JVMTI_ERROR_NONE is expected | |||
static void A() { | |||
log("TestTask.A: started"); | |||
atPointA = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if we are at the point where this flag has been set true, but we have not yet executed the monitorenter? Will the test pass if the StopThread is done a bit early here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the test will pass as the target virtual thread should still be in a good expected state.
#A.1: The StopThread
should still return the JVMTI_ERROR_THREAD_NOT_SUSPENDED error code.
#A.2: The StopThread
should return the JVMTI_ERROR_NONE as the target virtual thread has been mounted.
@sspitsyn This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 21 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is one nit related to code style.
@@ -104,7 +104,7 @@ public static void run() { | |||
} else { | |||
testTaskThread = Thread.ofPlatform().name("TestTaskThread").start(testTask); | |||
} | |||
testTask.ensureStarted(); | |||
testTask.ensureAtPointA(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Java Code Conventions recommends to use className and not variables while calling static methods. Same for 'ensureFinished()'.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you. Fixed now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Chris and Leonid, thank you for review!
/integrate |
Going to push as commit c2ef302.
Your commit was automatically rebased without conflicts. |
This is newly integrated test times out because it has a race in in the Test #A.1 and #A.2.
The main root cause is a print statement which can case target virtual thread to unpark and unmount.
This causes that the
StopThreads
unexpectedly fails with theJVMTI_ERROR_OPAQUE_FRAME
error code.The target thread can be in some other unexpected states if JVMTI
StopThread
is called before the target thread method
A()
reached the synchronized statement.The fix is to replace the
ensureStarted()
with theensureAtPointA()
.The fix also includes some simplifications related to clearing the target thread interrupt status.
Testing:
Hundreds of mach5 runs of
serviceability/jvmti/vthread
tests which include the fixedStopThreadTest
.TBD: To run mach5 tiers1-3.
The test does not fail with this fix anymore.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/13969/head:pull/13969
$ git checkout pull/13969
Update a local copy of the PR:
$ git checkout pull/13969
$ git pull https://git.openjdk.org/jdk.git pull/13969/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 13969
View PR using the GUI difftool:
$ git pr show -t 13969
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/13969.diff
Webrev
Link to Webrev Comment