-
Notifications
You must be signed in to change notification settings - Fork 710
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
jdk17 Thread/UncaughtExceptionsTest.java simulateUncaughtExitEvent missing from stderr #11930
Comments
Seems the test is expecting Thread-0 but OpenJ9 created Thread-3. We should check why that is and see if the difference in behavior can be resolved. |
Also seen in internal builds.
|
Considering the popularity of this failure across streams, it can be excluded before a fix is developed. |
Are you doing this or asking for me to do it? |
@llxia can the auto exclude feature exclude an individual test like |
The auto exclude feature on OpenJ9 issues can only be used to exclude functionality tests, since these are the only tests hosted from the openj9 repo. |
Or to put it another way - No. This test is an OpenJDK test. |
Currently, auto exclude feature only checks the playlist files in the same repo of the auto exclude comment. That is, to exclude functional test in openj9 repo, use the auto exclude comment in openj9 issue. For openjdk or system tests, the auto exclude comment should be used at Adopt test repo. In this case, you want to exclude in the openjdk problem list, not the playlist file. This feature is not implemented yet. |
- eclipse-openj9/openj9#14079 is a duplicate of adoptium/temurin-build#248. - eclipse-openj9/openj9#14091 is a duplicate of adoptium#1297. - eclipse-openj9/openj9#14095 is a duplicate of eclipse-openj9/openj9#11930. - Individual sub-tests of StringBuilder/HugeCapacity are excluded. Closes: eclipse-openj9/openj9#14079 Closes: eclipse-openj9/openj9#14091 Closes: eclipse-openj9/openj9#14095 Signed-off-by: Babneet Singh <sbabneet@ca.ibm.com>
- eclipse-openj9/openj9#14091 is a duplicate of adoptium#1297. - eclipse-openj9/openj9#14095 is a duplicate of eclipse-openj9/openj9#11930. - Individual sub-tests of StringBuilder/HugeCapacity are excluded. Closes: eclipse-openj9/openj9#14091 Closes: eclipse-openj9/openj9#14095 Signed-off-by: Babneet Singh <sbabneet@ca.ibm.com>
- eclipse-openj9/openj9#14091 is a duplicate of adoptium#1297. - eclipse-openj9/openj9#14095 is a duplicate of eclipse-openj9/openj9#11930. - Individual sub-tests of StringBuilder/HugeCapacity are excluded. Closes: eclipse-openj9/openj9#14091 Closes: eclipse-openj9/openj9#14095 Signed-off-by: Babneet Singh <sbabneet@ca.ibm.com>
- eclipse-openj9/openj9#14091 is a duplicate of adoptium#1297. - eclipse-openj9/openj9#14095 is a duplicate of eclipse-openj9/openj9#11930. - Individual sub-tests of StringBuilder/HugeCapacity are excluded. Closes: eclipse-openj9/openj9#14091 Closes: eclipse-openj9/openj9#14095 Signed-off-by: Babneet Singh <sbabneet@ca.ibm.com>
I was referring to TimerThread which doesn't call setName(). Hopefully the PR cleared it up. |
In my comment, |
It's the fact there is no name set in the constructor which is the problem, it doesn't matter how short the period is. The name isn't set in the TimerThread constructor, it calls Thread.newName() which consumes the "Thread-0" name. This causes the test to fail because it expects this name.It could have an impact on / confuse users which expect consistent thread names. Depending on the timing of the Attach API AttachHandler / FilelockTimer creation, an application can get different thread names from run to run. |
Issue eclipse-openj9/openj9#11930 The name isn't set in the TimerThread constructor, it calls Thread.newName() which consumes the "Thread-0" name. This causes the test to fail because it expects this name. This could have an impact on / confuse users which expect consistent thread names. Depending on the timing of the Attach API AttachHandler / FilelockTimer creation, an application can get different default thread names from run to run. Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>
Ok, that makes sense. Are there potentially multiple |
Issue eclipse-openj9/openj9#11930 The name isn't set in the TimerThread constructor, it calls Thread.genThreadName() which consumes the "Thread-0" name. This causes the test to fail because it expects this name. This could have an impact on / confuse users which expect consistent thread names. Depending on the timing of the Attach API AttachHandler / FilelockTimer creation, an application can get different default thread names from run to run. Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>
Or we at the point (since #16624) where the one |
The test only failed on "Thread-2" or "Thread-3" before I fixed the OpenJ9 code in #16624 |
Yes, exactly. |
Well, TimerThread is the only thing I know of, it's possible something else will be exposed, but I haven't seen a failure due to anything other than Thread-1 in a while. |
Will you be creating changes similar to ibmruntimes/openj9-openjdk-jdk#640 for earlier versions? |
Yes, I'll create some now and the rest later. |
Issue eclipse-openj9/openj9#11930 The name isn't set in the TimerThread constructor, it calls Thread.genThreadName() which consumes the "Thread-0" name. This causes the test to fail because it expects this name. This could have an impact on / confuse users which expect consistent thread names. Depending on the timing of the Attach API AttachHandler / FilelockTimer creation, an application can get different default thread names from run to run. Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>
Issue eclipse-openj9/openj9#11930 The name isn't set in the TimerThread constructor, it calls Thread.genThreadName() which consumes the "Thread-0" name. This causes the test to fail because it expects this name. This could have an impact on / confuse users which expect consistent thread names. Depending on the timing of the Attach API AttachHandler / FilelockTimer creation, an application can get different default thread names from run to run. Backport of ibmruntimes/openj9-openjdk-jdk#640 Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>
Issue eclipse-openj9/openj9#11930 The name isn't set in the TimerThread constructor, it calls Thread.newName() which consumes the "Thread-0" name. This causes the test to fail because it expects this name. This could have an impact on / confuse users which expect consistent thread names. Depending on the timing of the Attach API AttachHandler / FilelockTimer creation, an application can get different default thread names from run to run. Backport of ibmruntimes/openj9-openjdk-jdk#640 Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>
Issue eclipse-openj9/openj9#11930 The name isn't set in the TimerThread constructor, it calls Thread.newName() which consumes the "Thread-0" name. This causes the test to fail because it expects this name. This could have an impact on / confuse users which expect consistent thread names. Depending on the timing of the Attach API AttachHandler / FilelockTimer creation, an application can get different default thread names from run to run. Backport of ibmruntimes/openj9-openjdk-jdk#640 Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>
Issue eclipse-openj9/openj9#11930 The name isn't set in the TimerThread constructor, it calls Thread.genThreadName() which consumes the "Thread-0" name. This causes the test to fail because it expects this name. This could have an impact on / confuse users which expect consistent thread names. Depending on the timing of the Attach API AttachHandler / FilelockTimer creation, an application can get different default thread names from run to run. Backport of ibmruntimes/openj9-openjdk-jdk#640 Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>
Issue eclipse-openj9/openj9#11930 The name isn't set in the TimerThread constructor, it calls Thread.newName() which consumes the "Thread-0" name. This causes the test to fail because it expects this name. This could have an impact on / confuse users which expect consistent thread names. Depending on the timing of the Attach API AttachHandler / FilelockTimer creation, an application can get different default thread names from run to run. Backport of ibmruntimes/openj9-openjdk-jdk#640 Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>
Issue eclipse-openj9/openj9#11930 The name isn't set in the TimerThread constructor, it calls Thread.newName() which consumes the "Thread-0" name. This causes the test to fail because it expects this name. This could have an impact on / confuse users which expect consistent thread names. Depending on the timing of the Attach API AttachHandler / FilelockTimer creation, an application can get different default thread names from run to run. Backport of ibmruntimes/openj9-openjdk-jdk#640 Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>
Issue eclipse-openj9/openj9#11930 The name isn't set in the TimerThread constructor, it calls Thread.newName() which consumes the "Thread-0" name. This causes the test to fail because it expects this name. This could have an impact on / confuse users which expect consistent thread names. Depending on the timing of the Attach API AttachHandler / FilelockTimer creation, an application can get different default thread names from run to run. Backport of ibmruntimes/openj9-openjdk-jdk#640 Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>
Remove the OpenJ9 exclude for java/lang/Thread/UncaughtExceptionsTest.java now the problems have been resolved. Issue eclipse-openj9/openj9#11930 Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>
Unexclude the test via adoptium/aqa-tests#4699 |
Remove the OpenJ9 exclude for java/lang/Thread/UncaughtExceptionsTest.java now the problems have been resolved. Issue eclipse-openj9/openj9#11930 Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>
https://ci.eclipse.org/openj9/view/Test/job/Grinder/1503/
openjdk17 test java/lang/Thread/UncaughtExceptionsTest.java
The text was updated successfully, but these errors were encountered: