-
Bug
-
Resolution: Fixed
-
P4
-
17, 18
-
b15
-
x86_64
-
linux
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8295981 | 17.0.6-oracle | Kavya K S | P4 | Resolved | Fixed | b04 |
JDK-8296307 | 17.0.6 | Goetz Lindenmaier | P4 | Resolved | Fixed | b02 |
The following test failed in the JDK17 CI:
applications/runthese/RunThese24H.java
Here's a snippet from the log file:
[stress.process.err] java.lang.NullPointerException: Cannot invoke "String.startsWith(String)" because the return value of "java.lang.management.ThreadInfo.getLockName()" is null
[stress.process.err] at javasoft.sqe.tests.api.java.util.concurrent.JSR166TestCase.dumpTestThreads(JSR166TestCase.java:659)
[stress.process.err] at javasoft.sqe.tests.api.java.util.concurrent.JSR166TestCase.tearDownFail(JSR166TestCase.java:331)
[stress.process.err] at javasoft.sqe.tests.api.java.util.concurrent.JSR166TestCase.checkForkJoinPoolThreadLeaks(JSR166TestCase.java:387)
[stress.process.err] at javasoft.sqe.tests.api.java.util.concurrent.JSR166TestCase.tearDown(JSR166TestCase.java:364)
[stress.process.err] at javasoft.sqe.tests.api.junit.TestCase.invokeTestCase(TestCase.java:53)
[stress.process.err] at javasoft.sqe.javatest.lib.MultiTest.run(MultiTest.java:193)
[stress.process.err] at javasoft.sqe.javatest.lib.MultiTest.run(MultiTest.java:125)
[stress.process.err] at javasoft.sqe.tests.api.java.util.concurrent.RecursiveActionTest.main(RecursiveActionTest.java:35)
[stress.process.err] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[stress.process.err] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
[stress.process.err] at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[stress.process.err] at java.base/java.lang.reflect.Method.invoke(Method.java:568)
[stress.process.err] at applications.kitchensink.process.stress.modules.JckStressModule$TestRunner$1.run(JckStressModule.java:280)
I'm starting this failure in hotspot/test because it seems like a
test infrastructure bug, but I'm not sure. This failure mode also
seems familiar, but I couldn't find an existing bug that covers
this particular failure mode.
applications/runthese/RunThese24H.java
Here's a snippet from the log file:
[stress.process.err] java.lang.NullPointerException: Cannot invoke "String.startsWith(String)" because the return value of "java.lang.management.ThreadInfo.getLockName()" is null
[stress.process.err] at javasoft.sqe.tests.api.java.util.concurrent.JSR166TestCase.dumpTestThreads(JSR166TestCase.java:659)
[stress.process.err] at javasoft.sqe.tests.api.java.util.concurrent.JSR166TestCase.tearDownFail(JSR166TestCase.java:331)
[stress.process.err] at javasoft.sqe.tests.api.java.util.concurrent.JSR166TestCase.checkForkJoinPoolThreadLeaks(JSR166TestCase.java:387)
[stress.process.err] at javasoft.sqe.tests.api.java.util.concurrent.JSR166TestCase.tearDown(JSR166TestCase.java:364)
[stress.process.err] at javasoft.sqe.tests.api.junit.TestCase.invokeTestCase(TestCase.java:53)
[stress.process.err] at javasoft.sqe.javatest.lib.MultiTest.run(MultiTest.java:193)
[stress.process.err] at javasoft.sqe.javatest.lib.MultiTest.run(MultiTest.java:125)
[stress.process.err] at javasoft.sqe.tests.api.java.util.concurrent.RecursiveActionTest.main(RecursiveActionTest.java:35)
[stress.process.err] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[stress.process.err] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
[stress.process.err] at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[stress.process.err] at java.base/java.lang.reflect.Method.invoke(Method.java:568)
[stress.process.err] at applications.kitchensink.process.stress.modules.JckStressModule$TestRunner$1.run(JckStressModule.java:280)
I'm starting this failure in hotspot/test because it seems like a
test infrastructure bug, but I'm not sure. This failure mode also
seems familiar, but I couldn't find an existing bug that covers
this particular failure mode.
- backported by
-
JDK-8295981 Stress test times out because of long ObjectSynchronizer::monitors_iterate(...) operation
- Resolved
-
JDK-8296307 Stress test times out because of long ObjectSynchronizer::monitors_iterate(...) operation
- Resolved
- relates to
-
JDK-8270958 runThese times out with ZGC
- Closed
- links to
-
Commit openjdk/jdk17u-dev/f2a10fd2
-
Commit openjdk/jdk/a5e4def5
-
Review openjdk/jdk17u-dev/854
-
Review openjdk/jdk/5194
(2 links to)