The problem(abort/hung up) was found in customer's applet application. JDK : 5.0u11 OS : Windows Vista After analyzing the dump, Fujitsu found the thread where the problem occurred used JNIEnv* that belonged to another thread. --- [j2se/src/windows/native/sun/windows/awt_Toolkit.cpp] ... JNIEnv* AwtToolkit::m_env; HANDLE AwtToolkit::m_thread; void AwtToolkit::SetEnv(JNIEnv *env) { if (m_env != NULL) { // If already cashed (by means of embeddedInit() call). return; } m_thread = GetCurrentThread(); m_env = env; } JNIEnv* AwtToolkit::GetEnv() { return (m_env == NULL || m_thread != GetCurrentThread()) ? (JNIEnv*)JNU_GetEnv(jvm, JNI_VERSION_1_2) : m_env; } --- The above snippet is where JNIEnv * was used that was set by another thread. The code uses Windows API GetCurrentThread() that always returns a constant according to the following page. http://msdn.microsoft.com/en-us/library/ms683182.aspx --- GetCurrentThread() Return Value The return value is a pseudo handle for the current thread. Remarks A pseudo handle is a special constant that is interpreted ~~~~~~~~~~~~~~~~ as the current thread handle. The calling thread can use this handle to specify itself whenever a thread handle is required. Pseudo handles are not inherited by child processes. --- It is wrong that the AWT code uses the return value of GetCurrentThread() as thread identity. GetCurrentThreadId() should be used if Windows API is used. Additionally, we found the some codes where call AwtToolkit::GetEnv() and get returned JNIEnv* uses JNU_GetEnv(). These should to be fixed to call JNU_GetEnv(jvm, JNI_VERSION_1_2).
|