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

ThreadMXBean/Locks.java failed, blocked on wrong object.

    Details

    • Subcomponent:
    • Resolved In Build:
      b06
    • CPU:
      generic
    • OS:
      generic

      Backports

        Description

        The test failed in PIT of JDK9_dev (2014-02-08) With the following, somewhat cryptic error message:

        java.lang.RuntimeException: Thread WaitingThread is blocked on java.lang.Object@f241fc but got java.util.concurrent.Phaser$QNode@17b21d9
        at Locks.checkBlockedObject(Locks.java:98)
        at Locks.access$900(Locks.java:38)
        at Locks$CheckerThread.run(Locks.java:225)
        STATUS:Failed.`main' threw exception: java.lang.RuntimeException: Thread WaitingThread is blocked on java.lang.Object@f241fc but got java.util.concurrent.Phaser$QNode@17b21d9

        RULE java/lang/management/ThreadMXBean/Locks.java Exception java.lang.RuntimeException: Thread WaitingThread is blocked on java.lang.Object... but got java.util.concurrent.Phaser$QNode...

          Issue Links

            Activity

            Hide
            jbachorik Jaroslav Bachorík added a comment -
            Yes, I do. Actually, this is something we were discussing during the review a lot - that using a Phaser can actually block the thread intermittently even though it should be lock-free. All boils down to eg. grabbing the class loading lock when a certain (exceptional) path within the Phaser is taken for the first time :/

            Probably will need to preload all the touched classes ...
            Show
            jbachorik Jaroslav Bachorík added a comment - Yes, I do. Actually, this is something we were discussing during the review a lot - that using a Phaser can actually block the thread intermittently even though it should be lock-free. All boils down to eg. grabbing the class loading lock when a certain (exceptional) path within the Phaser is taken for the first time :/ Probably will need to preload all the touched classes ...
            Hide
            jbachorik Jaroslav Bachorík added a comment -
            It turns out this is something different.

            The Phaser is using park()/unpark() to wait for the desired condition. Unfortunately, park() will move the thread to WAITING state and confuse the test logic expecting the WAITING state would correspond to "objC.wait()" having been actually called.

            This will result either in "java.util.concurrent.Phaser$QNode@*" being reported as the lock name and the thread being in state WAITING or the lock name value "null" and thread state RUNNING (when the ThreadInfo is taken in between the moments when the Phaser unparks and objC.wait() is called).

            Thus Phaser (or any other java.util.concurrent construct using park()/unpark()) is not suitable for making sure the tested thread enters WAITING state.
            Show
            jbachorik Jaroslav Bachorík added a comment - It turns out this is something different. The Phaser is using park()/unpark() to wait for the desired condition. Unfortunately, park() will move the thread to WAITING state and confuse the test logic expecting the WAITING state would correspond to "objC.wait()" having been actually called. This will result either in "java.util.concurrent.Phaser$QNode@*" being reported as the lock name and the thread being in state WAITING or the lock name value "null" and thread state RUNNING (when the ThreadInfo is taken in between the moments when the Phaser unparks and objC.wait() is called). Thus Phaser (or any other java.util.concurrent construct using park()/unpark()) is not suitable for making sure the tested thread enters WAITING state.
            Hide
            kshefov Konstantin Shefov added a comment -
            Test name: java/lang/management/ThreadMXBean/Locks.java
            Show
            kshefov Konstantin Shefov added a comment - Test name: java/lang/management/ThreadMXBean/Locks.java
            Hide
            smarks Stuart Marks added a comment -
            TESTFAIL:java/lang/management/ThreadMXBean/Locks.java
            Show
            smarks Stuart Marks added a comment - TESTFAIL:java/lang/management/ThreadMXBean/Locks.java
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2a905e17a975
            User: jbachorik
            Date: 2014-03-11 13:29:18 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2a905e17a975 User: jbachorik Date: 2014-03-11 13:29:18 +0000
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/2a905e17a975
            User: lana
            Date: 2014-03-25 20:49:04 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/2a905e17a975 User: lana Date: 2014-03-25 20:49:04 +0000

              People

              • Assignee:
                jbachorik Jaroslav Bachorík
                Reporter:
                iaberg Ingemar Åberg
              • Votes:
                0 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: