Re: JVM apparently hanging

Bringing up an older thread….  To refresh memories, JNI/AWT/Classloading in different threads can cause apparent deadlocks.  A partial thread dump (not mine, but from earlier in this thread) looks like:

 

"Thread-0" daemon prio=5 tid=0x4d20c990 nid=0x2c1afe00 runnable [f0b94000..f0b96aa0]

       at java.lang.ClassLoader$NativeLibrary.load(Native Method)

       at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586)

       - locked <0x510e03a8> (a java.util.Vector)

       - locked <0x510e03c0> (a java.util.Vector)

       at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503)

       at java.lang.Runtime.loadLibrary0(Runtime.java:788)

       - locked <0x510e03f8> (a java.lang.Runtime)

 

 

 

"main" prio=5 tid=0x4d200f80 nid=0xa000ed98 waiting for monitor entry [bfffb000..bfffd498]

       at java.lang.Runtime.loadLibrary0(Runtime.java:780)

       - waiting to lock <0x510e03f8> (a java.lang.Runtime)

       at java.lang.System.loadLibrary(System.java:834)

       at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50)

       at java.security.AccessController.doPrivileged(Native Method)

       at java.util.zip.CRC32.<clinit>(CRC32.java:25)

       at java.util.zip.ZipInputStream.<init>(ZipInputStream.java:26)

 

 

 

We’re apparently having this same problem in Java 1.5.  A few questions:

 

1)       Has anybody found a good workaround?

2)       Has Apple acknowledged that this is a bug in the library loading?  Has a bug been filed?

3)       Our app uses JNI, but not AWT.  AWT is apparently brought into the picture as in #2 in the quoted message below, when we use com.apple.eio.FileManager.getFileCreator().  Why this starts loading AWT classes is beyond me and sounds a lot like a bug to me.

 

I haven’t started to try workarounds that change the timing of how different parts of our application are loaded, but any of that would just be a band-aid solution that we wouldn’t feel comfortable releasing a product with.  Any hints?

 

Thanks.

 

Nolan Johnson

 

>>I'm not even sure a workaround would work, since the actually hang, which

>>indirectly is causing the lock on java.lang.Runtime.loadLibrary0 to be

>>held, is happening in the native method

>>java.lang.ClassLoader$NativeLibrary.load, so it might hang there ANYWAY,

>>since the AWT thread will have the lock on loadLibrary0 (which it does in

>>my current situation).

> 

>Yes, but the timing might cause a workaround to succeed.  There's no way to

>tell except by attempting a workaround.

> 

>A few comments on the full thread-dump.

> 

>1) I see no apparent deadlocks, but I think the operative word is

>"apparent".  I have no idea what native-library dependencies there might

>be, nor what lib-setup code might be run, for the requested "awt" lib.

>That JNI-lib is pretty big, and no doubt complex.  If it happens to make

>any initializing callbacks to Java methods, it might easily deadlock and be

>invisible to a full thread-dump.

> 

>2) It's interesting that the loading of AWT appears to be triggered by the

>loading of the Component class, specifically its static initializer (named

><clinit>).

> 

 

 

 

 

CONFIDENTIALITY NOTICE

This e-mail transmission and any documents, files, or previous e-mail messages appended or attached to it, may contain information that is confidential or privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, printing, distribution, or use of the information contained or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone (303.894.3432) or return e-mail message (email@hidden) and delete the original transmission, its attachments, and any copies in your possession, custody or control. Thank you.