- 
    Type:
Bug
 - 
    Resolution: Fixed
 - 
    Priority:
  P4                     
     - 
    Affects Version/s: 17, 18
 - 
    Component/s: hotspot
 
- 
        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)