jdk deadlock bug in JDK 1.6.0_05?
Keith McNeill
mcneill at streambase.com
Wed Aug 27 19:38:50 PDT 2008
Nope, not solaris, it is on linux. But will try jstack -ml next time it
happens.
Thanks,
Keith
David Holmes - Sun Microsystems wrote:
> Hello Keith,
>
> There was bug whereby a thread that was blocked trying to acquire the
> monitor used for class initialization inside a synchronized
> block/method, would report that it was blocked acquiring the monitor
> associated with that synchronized block/method. But that was fixed in
> 6u2 and this is 6u5. Also note that monitors used for class
> initialization do not show "- locked XXXX" entries in the dump.
>
> I don't suppose this is on Solaris is it? If so a pstack dump (or
> jstack -ml) wold be more informative than the Java-level stack dump.
>
> David Holmes
> -----------
>
> Keith McNeill said the following on 08/28/08 06:34:
>> 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
>>
More information about the hotspot-dev
mailing list