APAR status
Closed as program error.
Error description
Error Message: Customer observed the deadlock after upgrading from 50SR12 to 50Sr13:- 1LKDEADLOCK Deadlock detected !!! NULL --------------------- NULL 2LKDEADLOCKTHR Thread "WebContainer : 5" (0x3A1BA300) 3LKDEADLOCKWTR is waiting for: 4LKDEADLOCKMON sys_mon_t:0x3410FFE0 infl_mon_t: 0x34110008: 4LKDEADLOCKOBJ sun/misc/Launcher$AppClassLoader@7002A0B0/7002A0BC: 3LKDEADLOCKOWN which is owned by: 2LKDEADLOCKTHR Thread "WebContainer : 6" (0x3A1BA700) 3LKDEADLOCKWTR which is waiting for: 4LKDEADLOCKMON sys_mon_t:0x35F1DB80 infl_mon_t: 0x35F1DBA8: 4LKDEADLOCKOBJ org/eclipse/core/launcher/Main$StartupClassLoader@705D49C0/705D4 9CC: 3LKDEADLOCKOWN which is owned by: 2LKDEADLOCKTHR Thread "WebContainer : 5" (0x3A1BA300) NULL . Stack Trace: Stacks of the threads involved in deadlock:- 3XMTHREADINFO "WebContainer : 5" (TID:0x3A1BA300, sys_thread_t:0x39B179D4, state:B, native ID:0x0114701B) prio=5 at java/lang/ClassLoader.loadClass(ClassLoader.java:642(Compiled Code)) at java/lang/ClassLoader.loadClass(ClassLoader.java(Compiled Code)) at org/eclipse/osgi/framework/internal/core/BundleLoader.findClass( BundleLoader.java:352(Compiled Code)) at org/eclipse/osgi/framework/internal/core/BundleLoader.findClass( BundleLoader.java:347(Compiled Code)) at org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader.loadCla ss(DefaultClassLoader.java:79(Compiled Code)) at java/lang/ClassLoader.loadClass(ClassLoader.java:642(Compiled Code)) at com/ibm/ws/bootstrap/ExtClassLoader.loadClass(ExtClassLoader.jav a:87(Compiled Code)) at java/lang/ClassLoader.loadClass(ClassLoader.java:616(Compiled Code)) at com/ibm/ws/classloader/ProtectionClassLoader.loadClass(Protectio nClassLoader.java:58(Compiled Code)) at com/ibm/ws/classloader/ProtectionClassLoader.loadClass(Protectio nClassLoader.java:54(Compiled Code)) at com/ibm/ws/classloader/CompoundClassLoader.loadClass(CompoundCla ssLoader.java:399(Compiled Code)) at java/lang/ClassLoader.loadClass(ClassLoader.java:616(Compiled Code)) at com/ibm/ws/classloader/CompoundClassLoader.loadClass(CompoundCla ssLoader.java:399(Compiled Code)) at java/lang/ClassLoader.loadClass(ClassLoader.java:616(Compiled Code)) at org/apache/xerces/parsers/ObjectFactory.findProviderClass(Byteco de PC:55) at org/apache/xerces/parsers/ObjectFactory.newInstance(Bytecode PC:3) 3XMTHREADINFO "WebContainer : 6" (TID:0x3A1BA700, sys_thread_t:0x39B17C70, state:B, native ID:0x00E8F00D) prio=5 at java/lang/ClassLoader.loadClass(ClassLoader.java:616(Compiled Code)) at java/lang/Class.forNameImpl(Native Method) at java/lang/Class.forName(Class.java:130(Compiled Code)) at org/eclipse/osgi/framework/util/SecureAction.forName(SecureActio n.java:309(Compiled Code)) at org/eclipse/osgi/framework/internal/protocol/StreamHandlerFactor y.getBuiltIn(StreamHandlerFactory.java:58(Compiled Code)) at org/eclipse/osgi/framework/internal/protocol/StreamHandlerFactor y.createURLStreamHandler(StreamHandlerFactory.java:86) at java/net/URL.getURLStreamHandler(URL.java:1142(Compiled Code)) at java/net/URL.<init>(URL.java:607(Compiled Code)) at java/net/URL.<init>(URL.java:499(Compiled Code)) at sun/misc/URLClassPath$FileLoader.getResource(URLClassPath.java:1 158(Compiled Code)) at sun/misc/URLClassPath$FileLoader.findResource(URLClassPath.java: 1148(Compiled Code)) at sun/misc/URLClassPath.findResource(URLClassPath.java:301(Compile d Code)) at java/net/URLClassLoader$3.run(URLClassLoader.java:806(Compiled Code)) at java/security/AccessController.doPrivileged(AccessController.jav a:214) at java/net/URLClassLoader.findResource(URLClassLoader.java:803(Com piled Code)) at java/lang/ClassLoader.getResource(ClassLoader.java:431(Compiled Code)) at java/lang/ClassLoader.getResource(ClassLoader.java:426(Compiled Code)) . N/A
Local fix
N/A
Problem summary
The OSGi framework of WAS runs on does its own protocol handling. When a resource is loaded, it tries to load the protocol handler using Class.forName. The loader which use to load the OSGi classes is a child of Launcher$AppClassLoader, so when it tries to load the handler, it already has the lock on AppClassLoader (due to the URLClassLoader.findResource API synchronization) but then tries to load from a child loader. In parallel if some other thread is going down a standard loadClass path it already has that child classloader lock and will require the AppClassLoader and hence the deadlock.
Problem conclusion
This defect will be fixed in: 5.0.0 SR14 . The JVM has been updated to handle the deadlock scenario when custom classloaders loads the classes in above fashion.
Temporary fix
Comments
APAR Information
APAR number
IV25876
Reported component name
JAVA 5 CLASS LI
Reported component ID
620500130
Reported release
500
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2012-08-08
Closed date
2012-08-16
Last modified date
2012-09-06
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
JAVA 5 CLASS LI
Fixed component ID
620500130
Applicable component levels
R500 PSY
UP
[{"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSCVQ3Y","label":"Java Class Libraries"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"5.0","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
06 September 2012