JDK-8032382 : Classloading lock owned by a thread that hasn't appeared to sync on it blocking other threads from proceeding.
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang:class_loading
  • Affected Version: 7u45
  • Priority: P2
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2014-01-21
  • Updated: 2014-01-29
  • Resolved: 2014-01-29
Related Reports
Duplicate :  
Description
According to the thread dump 0x00000000e0463f10 is a 
ReentrantLock$NonfairSync which two other threads are waiting to lock. It is 
not clear from the thread dump which thread currently owns this lock, however 
using kjdb & SA we see the following:

hsdb> inspect 0x00000000e0463f10
instance of Oop for java/util/concurrent/locks/ReentrantLock$NonfairSync @
0xe0463f10 @ 0xe0463f10 (size = 32)
_mark: 49
exclusiveOwnerThread: Oop for weblogic/work/ExecuteThread @ 0xe075e5b8 Oop
for weblogic/work/ExecuteThread @ 0xe075e5b8
head: Oop for java/util/concurrent/locks/AbstractQueuedSynchronizer$Node @
0xf869b810 Oop for java/util/concurrent/locks/AbstractQueuedSynchronizer$Node
0xf869b810
tail: Oop for java/util/concurrent/locks/AbstractQueuedSynchronizer$Node @
0xf88cf6f0 Oop for java/util/concurrent/locks/AbstractQueuedSynchronizer$Node
0xf88cf6f0
state: 1

inspect the owner thread:

hsdb> inspect 0xe075e5b8
instance of Oop for weblogic/work/ExecuteThread @ 0xe075e5b8 @ 0xe075e5b8
(size = 192)
_mark: 46912794892362
name: [C @ 0xe075e678 Oop for [C @ 0xe075e678
priority: 5
...
...
activeName: "[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default
(self-tuning)'" @ 0xe07843c0 Oop for java/lang/String @ 0xe07843c0


x:c>threads | grep ExecuteThread


x:c>thread 0x6451
Thread: id = 0x6451 [ACTIVE] ExecuteThread: '0' for queue:
'weblogic.kernel.Default (self-tuning)' JavaThread
Oop=sun.jvm.hotspot.oops.Instance@e075e5b8 SP=0x4152f6a0 Stack: 0x4152f6a0 -
0x4152f9c0 used = 0x320(800b)

Thread nid=0x6451: (state = BLOCKED, current Java SP = 0x4152f8a0

 - java.lang.Object.wait(long) @bci=0, pc=0x2aaaab81bf67,
methodOop=0xd0002758 (Compiled frame; information may be imprecise)
 - java.lang.Object.wait() @bci=2, line=503, pc=0x2aaaab198058,
methodOop=0xd0002948 (Interpreted frame)
 - weblogic.work.ExecuteThread.waitForRequest() @bci=8, line=232,
pc=0x2aaaab198058, methodOop=0xd1b04c70 (Interpreted frame)
 - weblogic.work.ExecuteThread.run() @bci=120, line=266, pc=0x2aaaab87bf60,
methodOop=0xd1b04eb0 (Compiled frame)


This corresponds to the thread dump:

"[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default
(self-tuning)'" daemon prio=10 tid=0x00002aaab495b800 nid=0x6451 in
Object.wait() [0x000000004152f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Object.java:503)
        at weblogic.work.ExecuteThread.waitForRequest(ExecuteThread.java:232)
        - locked <0x00000000e075e5b8> (a weblogic.work.ExecuteThread)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:266)

It is not clear how this thread came to own the lock.


Comments
Duplicate of JDK-7011862
29-01-2014

The attached log shows a stack trace (with the repetition substituted with "...") printed from InterpreterRuntime::throw_StackOverflowError. For some reason (I'm looking into it) we're attempting to load a class at the end of this stack. Unfortunately somehow or other ConcurrentHashMap.put() dies while the exclusiveOwnerThread is set with no way to unlock. I'm not completely sure how this is possible as there doesn't seem to be anything left to cause a StackOverflow after setting the exclusiveOwnerThread in nonfairTryAcquire() unless scanAndLockForPut() is called from ConcurrentHashMap.put() or we already own this lock somehow.
28-01-2014

Moving this to java.lang:class_loading for now, pending further diagnostic effort to know if this is hotspot, j.u.cconcurrent or just caused by an async exception or stack overflow.
21-01-2014