Thread::current() and JNI pthread interaction

[Andreas Eriksson]

Hi,

I'm investigating a bug where JNI code (attached, compilation 
instructions below) is using pthread_key_create with a destructor to 
detach the thread from the JVM when the thread is exiting.
This solution works well when running on Solaris or a 32 bit JVM on 
Linux, but when run on 64 bit JVM on Linux the threads hang when detaching.

It turns out that for 64 bit Linux the JVM is also using the 
pthread_key_create, to store the Thread::current() value in a thread 
local storage.
Ssince the thread local storages are reset in Thread::~Thread 
(ThreadLocalStorage::set_thread(NULL)), before the JNI destructor runs, 
we run detachCurrentThread on a thread that has NULL as current thread.
With a product build this breaks locks/monitors, and the threads hang. 
With a debug build an assert in Thread::current() is hit instead.

Everything works if detachCurrentThread is called from the main logic 
instead.

Is this considered a bug, or maybe this behavior is expected?

Regards,
Andreas

Compile native:
# 64bit
JAVA_HOME=/java/linux-x64/jdk1.7.0_45
gcc -shared -fpic  -o libNative.so  -I$JAVA_HOME/include 
-I$JAVA_HOME/include/linux -lstdc++ Callback_Native.cpp

# 32bit
JAVA_HOME=/java/linux-i586/jdk1.7.0_45
gcc -v -m32 -shared -fpic  -o libNative.so  -I$JAVA_HOME/include 
-I$JAVA_HOME/include/linux -lstdc++ Callback_Native.cpp

Compile java (from callback/src/main/java):
JAVA_HOME=/java/linux-x64/jdk-1.7.0_45
$JAVA_HOME/bin/javac com/test/callback/CallbackTest.java
$JAVA_HOME/bin/javac com/test/callback/App.java

To run: (from callback/src/main/java)
NATIVE=../../../native
$JAVA_HOME/bin/java -Djava.library.path=$NATIVE com.test.callback.App
-------------- next part --------------
A non-text attachment was scrubbed...
Name: callback_jni.tar.gz
Type: application/gzip
Size: 3508 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140205/5a164cf2/callback_jni.tar.gz