JVMs are deadlocked waiting on resources deep in the Java environment in ObjectStreamClass.

Please see stack trace in the comments part
  xxxxx@xxxxx   2004-09-20
  xxxxx@xxxxx   2004-09-20

As far as we know, there is no workaround
  xxxxx@xxxxx   2004-09-20

There is a deadlock here which seems to occur relatively rarely.  There is
a simple but inefficient fix that introduces lock contention on a single 
shared lock.  We need to fix this more carefully in several places.
For now I'll commit this to a later Tiger update release.

I think we ran into this issue with 1.4.2_07, but it's hard to tell given the lack of (public) details on this issue.  Also, the change log for 1.4.2_08 indicates this bug was fixed, but here it's reported as "In progress".  What's the real current status?  Here are the stack traces from the deadlock.  Can someone confirm this is the same bug?

Thank you!

Found one Java-level deadlock:
=============================
"task":
  waiting to lock monitor 0x080c083c (object 0x465db890, a sun.misc.Launcher$AppClassLoader),
  which is held by "main"
"main":
  waiting to lock monitor 0x080c08ac (object 0x54a61ab8, a java.lang.Class),
  which is held by "task"

Java stack information for the threads listed above:
===================================================

"main":
 at sun.security.util.SignatureFileVerifier.<init>(SignatureFileVerifier.java:110)
 - waiting to lock <0x54a61ab8> (a java.lang.Class)
 at java.util.jar.JarVerifier.processEntry(JarVerifier.java:261)
 at java.util.jar.JarVerifier.update(JarVerifier.java:194)
 at java.util.jar.JarFile.initializeVerifier(JarFile.java:300)
 at java.util.jar.JarFile.getInputStream(JarFile.java:362)
 - locked <0x465ee0e8> (a java.util.jar.JarFile)
 at sun.misc.URLClassPath$5.getInputStream(URLClassPath.java:619)
 at sun.misc.Resource.getBytes(Resource.java:57)
 at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
 at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
 at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
 - locked <0x465db890> (a sun.misc.Launcher$AppClassLoader)
 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
 - locked <0x465db890> (a sun.misc.Launcher$AppClassLoader)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
 at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
 - locked <0x465db890> (a sun.misc.Launcher$AppClassLoader)
 at com.miranda.icontrol.densite.starter.MTDensiteStarter.main(MTDensiteStarter.java:525)

Found 1 deadlock.

"task":
 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:260)
 - waiting to lock <0x465db890> (a sun.misc.Launcher$AppClassLoader)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
 at java.security.Provider.loadProvider(Provider.java:149)
 at java.security.Security$3.run(Security.java:441)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.security.Security.loadOneMoreProvider(Security.java:438)
 - locked <0x54a61ab8> (a java.lang.Class)
 at java.security.Security.getEngineClassName(Security.java:647)
 - locked <0x54a61ab8> (a java.lang.Class)
 at java.security.Security.getEngineClassName(Security.java:683)
 at java.security.Security.getImpl(Security.java:1132)
 at java.security.MessageDigest.getInstance(MessageDigest.java:120)
 at java.rmi.dgc.VMID.computeAddressHash(VMID.java:139)
 at java.rmi.dgc.VMID.<clinit>(VMID.java:27)
 at sun.rmi.transport.DGCClient.<clinit>(DGCClient.java:57)
 at sun.rmi.transport.LiveRef.read(LiveRef.java:274)
 at sun.rmi.server.UnicastRef.readExternal(UnicastRef.java:464)
 at java.rmi.activation.ActivationID.readObject(ActivationID.java:235)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:324)
 at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:838)
 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1746)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
 at sun.rmi.server.ActivatableRef.readExternal(ActivatableRef.java:322)
 at java.rmi.server.RemoteObject.readObject(RemoteObject.java:420)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:324)
 at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:838)
 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1746)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
 at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1845)
 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1769)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
 at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
 at net.jini.discovery.IncomingUnicastResponse.<init>(IncomingUnicastResponse.java:72)
 at net.jini.discovery.LookupLocatorDiscovery$LocatorReg.doUnicastDiscovery(LookupLocatorDiscovery.java:242)
 at net.jini.discovery.LookupLocatorDiscovery$LocatorReg.tryGetProxy(LookupLocatorDiscovery.java:217)
 at net.jini.discovery.LookupLocatorDiscovery.regTryGetProxy(LookupLocatorDiscovery.java:891)
 at net.jini.discovery.LookupLocatorDiscovery.access$7(LookupLocatorDiscovery.java:887)
 at net.jini.discovery.LookupLocatorDiscovery$DiscoveryTask.tryOnce(LookupLocatorDiscovery.java:371)
 at com.sun.jini.thread.RetryTask.run(RetryTask.java:160)
 at com.sun.jini.thread.TaskManager$TaskThread.run(TaskManager.java:271)

Still happens in 1.4.2_09

Is this still being worked on? Has is it been fixed in any 1.5 release? We are encountering this problem quite often and have no desire to switch to a single thread of execution in our application... We are using 1.4.2_09

We got similar deadlock using JDK 1.5.0_06. Can anyone shade some light on the progress with this one and if it is being handled?

Has this been fixed in Java 1.6? What is the status, this bug has been marked in progress for 2 years now.

We have found another variant (occurs rarely):
Found one Java-level deadlock:
=============================
"KMAgentStarter":
  waiting to lock monitor 0x230de20c (object 0x0bd44ee0, a java.util.Collections$SynchronizedSet),
  which is held by "IrmaUserManager-StartRunner"
"IrmaUserManager-StartRunner":
  waiting to lock monitor 0x230de30c (object 0x0bd01eb0, a sun.misc.Launcher$AppClassLoader),
  which is held by "KMAgentStarter"
 
Java stack information for the threads listed above:
===================================================
"KMAgentStarter":
        at java.util.Collections$SynchronizedSet.equals(Collections.java:1659)
        - waiting to lock <0x0bd44ee0> (a java.util.Collections$SynchronizedSet)
        at javax.security.auth.SubjectDomainCombiner.combine(SubjectDomainCombiner.java:203)
        - locked <0x0bd42f48> (a javax.security.auth.SubjectDomainCombiner$WeakKeyValueMap)
        at java.security.AccessControlContext.goCombiner(AccessControlContext.java:390)
        at java.security.AccessControlContext.optimize(AccessControlContext.java:304)
        at java.security.AccessController.checkPermission(AccessController.java:426)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
        at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265)
        - locked <0x0bd01eb0> (a sun.misc.Launcher$AppClassLoader)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at java.net.URL.getURLStreamHandler(URL.java:1141)
        at java.net.URL.<init>(URL.java:572)
        at java.net.URL.<init>(URL.java:464)
        at java.net.URL.<init>(URL.java:413)
        at org.mortbay.resource.Resource.newResource(Resource.java:135)
... rest omitted

"IrmaUserManager-StartRunner":
        at java.lang.Class.getDeclaredMethods0(Native Method)
        at java.lang.Class.privateGetDeclaredMethods(Class.java:2395)
        at java.lang.Class.getDeclaredMethod(Class.java:1907)
        at java.io.ObjectStreamClass.getPrivateMethod(ObjectStreamClass.java:1354)
        at java.io.ObjectStreamClass.access$1700(ObjectStreamClass.java:52)
        at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:421)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:400)
        at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:297)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1035)
        at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
        at java.util.ArrayList.writeObject(ArrayList.java:569)
... rest omitted

Closed, will not be fixed?
You can't be serious. If I can't rely on proper thread handling inside Java then I can't use it in any sensible environment.
Please reconsider fixing this!

How is this part of JDK 7 build 57 and closed as not fixed?