JDK-6740526 : sun/management/HotspotThreadMBean/GetInternalThreads.java test failed
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs14
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-08-22
  • Updated: 2012-02-01
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u14Fixed 7Fixed hs14Fixed
Related Reports
Relates :  
Description
sun/management/HotspotThreadMBean/GetInternalThreads.java fails the following assert:

    Internal Error (src/share/vm/runtime/mutex.cpp:1292)
    Error: acquiring lock Terminator_lock/16 out of order
        with lock Threads_lock/15 -- possible deadlock

So far this test has failed on Solaris AMD64 Server VM,
Linux IA32 Server VM, Win-AMD64 Server VM, Win32 Server VM,
Linux AMD64 Server VM and Solaris X86 Server VM. The nightly
search tool did not find any failures for this test in the
2008.08.19 nightly.
New MM_REGRESSION failures (from 2008.08.21)
*   sun/management/HotspotThreadMBean/GetInternalThreads.java
        This test failed the following assertion:

            Internal Error (src/share/vm/runtime/mutex.cpp:1292)
            Error: acquiring lock Terminator_lock/16 out of order with
                lock Threads_lock/15 -- possible deadlock

        on all Client and Server VM configs.

See the MM_REGRESSION results in the following nightly:

http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2008-08-21/Serv_Baseline/index.html

Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b33eef719520
26-08-2008

EVALUATION The root cause is described in the comment section and the fix could be as simple as removing the lock acquisition when calling ThreadClosure->do_thread(WatcherThread) and just do a NULL check. The potential problem of this is that when examing the fields of WatcherThread, it could have been already terminated and its memory could have been purged by the memory subsystem, however, considerig the VM is also terminating during the termination of WatcherThread and the VM termination occurs at safepoint, the chance of the fatality is extremely low and the worst case is the call site gets the wrong information about the WatcherThread which is probably better than simply crashing.
22-08-2008