[GERONIMO-3141] potential deadlock in TransformerCollection

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.0-M6
• Fix Version/s: 2.0-M6
• Security Level: public (Regular issues)
• Assignee: Kevan Lee Miller
• Reporter: Kevan Lee Miller
• Created: 06/May/07 14:29
• Updated: 09/May/07 23:33
• Resolved: 09/May/07 23:33

Description

Jason Dillon ran into the following deadlock:

Full thread dump Java HotSpot(TM) Client VM (1.5.0_11-b03 mixed mode):

"Finalizer" daemon prio=1 tid=0x080ceec8 nid=0x6b27 waiting for monitor entry [0xea45c000..0xea45d130]
at org.apache.geronimo.transformer.TransformerCollection.transform(TransformerCollection.java:35)
at sun.instrument.TransformerManager.transform(TransformerManager.java:122)
at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:155)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:82)
at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)

"main" prio=1 tid=0x0805e6e8 nid=0x6b22 waiting for monitor entry [0xffc7c000..0xffc7d9a8]
at java.lang.ClassLoader.findBootstrapClass(Native Method)
at java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:891)
at java.lang.ClassLoader.loadClass(ClassLoader.java:301)

• locked <0xeaad5588> (a sun.misc.Launcher$ExtClassLoader)
  at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
• locked <0xeaad31e0> (a sun.misc.Launcher$AppClassLoader)
  at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
• locked <0xeaad31e0> (a sun.misc.Launcher$AppClassLoader)
  at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
  at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
• locked <0xeaad31e0> (a sun.misc.Launcher$AppClassLoader)
  at java.lang.ClassLoader.defineClass1(Native Method)
  at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
  at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
  at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
  at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
  at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
  at java.security.AccessController.doPrivileged(Native Method)
  at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
  at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
• locked <0xeaad31e0> (a sun.misc.Launcher$AppClassLoader)
  at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
• locked <0xeaad31e0> (a sun.misc.Launcher$AppClassLoader)
  at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
  at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
• locked <0xeaad31e0> (a sun.misc.Launcher$AppClassLoader)

"VM Thread" prio=1 tid=0x080cb160 nid=0x6b23 runnable

"VM Periodic Task Thread" prio=1 tid=0x081ba5d0 nid=0x6b2b waiting on condition

Found one Java-level deadlock:
=============================
"Finalizer":
waiting to lock monitor 0x080cfe04 (object 0xeaad31e0, a sun.misc.Launcher$AppClassLoader),
which is held by "main"
"main":
waiting to lock monitor 0x080cfe84 (object 0xee5e4a20, a [[I),
which is held by "Finalizer"

Gianny Damour found the following Sun bug report http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5088398. I also ran across the following OpenJPA jira – https://issues.apache.org/jira/browse/OPENJPA-98

Same basic issue – ClassFileTransformer.transform() is causing two threads to obtain two ClassLoader locks in a different order – thus the deadlock...

Barring a fix from Sun (IBM JDK fixed the problem reported in the OpenJPA Jira), moving geronimo-transformer.jar to the system classpath may avoid this problem (as suggested within the sun bug report). We may need all ClassFileTransformer implementation jars to be on the system classpath...