United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6740526 sun/management/HotspotThreadMBean/GetInternalThreads.java test failed
JDK-6740526 : sun/management/HotspotThreadMBean/GetInternalThreads.java test failed

Details
Type:
Bug
Submit Date:
2008-08-22
Status:
Closed
Updated Date:
2012-02-01
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
hotspot
OS:
generic
Sub-Component:
runtime
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs14
Fixed Versions:
hs14 (b05)

Related Reports
Backport:
Backport:
Relates:

Sub Tasks

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

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.
                                     
2008-08-22
EVALUATION

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



Hardware and Software, Engineered to Work Together