deadlock with jni NewDirectByteBuffer called from multiple threads introduced in JDK 1.6.0_04

[Keith McNeill]

Here is a gdb stack dump from linux64.  Look for NewDirectByteBuffer to 
find the calls.

David Holmes - Sun Microsystems wrote:
> Hi Keith,
>
> What platform are you on? Can you see where threads block inside 
> NewDirectByteBuffer?
>
> On Solaris pstack would show you what state the process in. I think 
> linux has similar functionality, but don't know about Windows.
>
> David Holmes
>
> Keith McNeill said the following on 01/09/09 06:22:
>> Our software has a C++ network layer using a large java runtime via 
>> JNI.  When new clients connect to our server we make some 
>> NewDirectByteBuffer calls so that we can pass data from the c++ 
>> network layer to the the java runtime system.   We use the JVM 
>> invocation JNI interface (i.e. we startup with our own exe rather 
>> than java.exe).  This same basic setup has been running for several 
>> years.
>>
>> We have recently found that we can get what appears to be deadlock 
>> within calls to NewDirectByteBuffer.   Debugging we can see multiple 
>> threads down in the guts of NewDirectByteBuffer blocked.    Once the 
>> deadlock occurs the JVM is hosed.  We can't get stack dumps from it, 
>> can't do anything with it. This problem is complicated to reproduce 
>> but we can do it reliably.
>> We have been able to reproduce this with JDK 1.6.0_04 through JDK 
>> 1.6.0_11.  We haven't been able to reproduce with JDK 1.6.0_03 down 
>> through JDK 1.5.
>>
>> Any suggestions on the best way to debug this JDK problem?
>>
>> Keith
>>
>>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: stack.txt
Url: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20090108/5e4a5e14/attachment.txt