Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8265489

Stress test times out because of long ObjectSynchronizer::monitors_iterate(...) operation

    XMLWordPrintable

Details

    • b15
    • x86_64
    • linux

    Backports

      Description

        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.

        Attachments

          Issue Links

            Activity

              People

                lmesnik Leonid Mesnik
                dcubed Daniel Daugherty
                Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved: