jdk deadlock bug in JDK 1.6.0_05?

Keith McNeill mcneill at streambase.com
Wed Aug 27 13:34:34 PDT 2008


A customer of ours is reporting a hang problem.  They took a thread dump 
during the hang and the thread dump reported a deadlock.  The relavent 
portion of the thread dump is  (there are approx 500 threads running in 
the application):

......
Found one Java-level deadlock:
=============================
"Thread-135314":
      waiting to lock monitor 0x08ab51e0 (object 0x78c478e0, a 
java.util.ArrayList),
      which is held by "Thread-997"
"Thread-997":
      waiting to lock monitor 0x08abc554 (object 0x78089d38, a 
com.streambase.sb.runtime.ParallelModule$ParallelLockee),
      which is held by "Thread-11620"
"Thread-11620":
      waiting to lock monitor 0x08ab51e0 (object 0x78c478e0, a 
java.util.ArrayList),
      which is held by "Thread-997"

Java stack information for the threads listed above:
===================================================
"Thread-135314":

    at
    com.streambase.sb.runtime.sbd.OutputQueue.subscribe(OutputQueue.java:361)

    - waiting to lock <0x78c478e0> (a java.util.ArrayList)
    at
    com.streambase.sb.sbd.InnerDequeueHandle.subscribe(InnerDequeueHandle.java:310)

    at
    com.streambase.sb.sbd.XmlRpcHandlerManager$SUBSCRIBEHandler.process(XmlRpcHandlerManager.java:181)

    at
    com.streambase.sb.xmlrpc.XmlRpcManager.process(XmlRpcManager.java:208)
    at
    com.streambase.sb.sbd.XmlRpcHandlerManager.processXmlRpcRequest(XmlRpcHandlerManager.java:119)

    at
    com.streambase.sb.sbd.StreamBaseServer.processXmlRpcRequest(StreamBaseServer.java:174)

    at
    com.streambase.sb.sbd.StreamBaseServer.processXmlRpcRequestJni(StreamBaseServer.java:164)


"Thread-997":

    at
    com.streambase.sb.sbd.StreamBaseNode.enqueue(StreamBaseNode.java:797)
    - waiting to lock <0x78089d38> (a
    com.streambase.sb.runtime.ParallelModule$ParallelLockee)

"Thread-11620":

    at cm._default_.sbd_1219465761228_1.s___Monitor_Input_O_S_(Unknown
    Source)
    - waiting to lock <0x78c478e0> (a java.util.ArrayList)
    at
    cm._default_.sbd_1219465761228_1.op___Monitoring_Routing__0(Unknown
    Source)
    at
    cm._default_.sbd_1219465761228_1.op___Monitor_Input_Monitor_Filter__0(Unknown
    Source)
    at cm._default_.sbd_1219465761228_1.s___Monitor_Input_(Unknown Source)
    at
    cm._default_.sbd_1219465761228_1._enqueue_Tuples_1_Monitor_Input_(Unknown
    Source)
    at cm._default_.sbd_1219465761228_1.enqueueTuples(Unknown Source)
    at
    com.streambase.sb.runtime.MainModule.enqueueTuples(MainModule.java:232)
    at
    com.streambase.sb.sbd.StreamBaseNode.enqueue(StreamBaseNode.java:799)
    - locked <0x78089d38> (a
    com.streambase.sb.runtime.ParallelModule$ParallelLockee)


Found 1 deadlock.
--------------------

The key is that the thread dump thinks that Thread-997 holds monitor 
0x08ab51e0 (object 0x78c478e0).

If I believe the thread dump output then that thread doesn't hold that 
monitor/lock:
--------------
"Thread-997":

    at
    com.streambase.sb.sbd.StreamBaseNode.enqueue(StreamBaseNode.java:797)
    - waiting to lock <0x78089d38> (a
    com.streambase.sb.runtime.ParallelModule$ParallelLockee)

-------------------
There is no locked <0x78c478e0> in that thread. In fact there is no 
locked <0x78c478e0> in the entire stack dump. So no one is holding that 
lock

I could believe that in the past Thread-997 held that lock. But it 
doesn't now....at least according to the thread dump.

Looking through the code the thread stack traces seem quite reasonable. 
All of the locked and waiting on locks seem correct except for the 
threads waiting on Thread-997 for a lock.

Note that "Thread-997" is coming in via JNI

I can see a couple of possibilities:

1) Thread dump is lying and the dead lock is happening somewhere else
2) JVM has a bug in that Thread-997 hasn't released the lock for some 
reason.

Any suggestions on how to debug the problem with the customer?  It 
doesn't seem like that the thread dump output is giving me good information.

Thanks,

Keith

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080827/c924b4cd/attachment.html 


More information about the hotspot-dev mailing list