[tested under 6u30 and 6u35]
When starting several applets continuously and "tab browse" feature is enabled in IE,
applets will be launched in each tab.
IE crashes while loading applet and close tabs, but automatically reopens and restart applet.
[Attached reproduce test]
This applet just obtains Java version and display it on IE screen.
1. Save the attached file in local
2. Open Internet Explorer (make sure "Tab browse" feature is enabled)
3. From command prompt, go to the saved file location and run tp.sh
-> It will launch JavaApplet in different tab one by one
-> If unable to reproduce, please add the more lines in tp.sh to increase the number of Applet to be launched
We suspect this is syncronization issue in JavaVM_GetJNIEnv().
deploy/src/plugin/win32/plugin2/common/JavaVM.c.
// Note: locking would be needed in order to make this code 100% correct.
// It's difficult to implement this without another initialization entry
// point called from DllMain. In practice this will be called in a
// sufficiently single threaded fashion when the JVM initialization occurs.
JNIEnv* JavaVM_GetJNIEnv()
{
JNIEnv* env = NULL;
jint res = 0;
if (!initialized) {
if (!InitializeJVM()) {
return NULL;
}
initialized = 1;
}
res = (*jvm)->AttachCurrentThread(jvm, (void**) &env, NULL);
if (res < 0)
return NULL;
return env;
}
While previous Applet launches JVM, it seems like next Applet tries to attach to the launching JVM.
In fact, our customer reported that when they encounter this issue with debug version of JVM, assertion failed in allocate_threadObj(), thread.cpp in hotspot.
void JavaThread::allocate_threadObj(Handle thread_group, char* thread_name, bool daemon, TRAPS) {
assert(thread_group.not_null(), "thread group should be specified") ; <-
And this allocate_threadObj() is called from attach_current_thread() in jni.cpp
static jint attach_current_thread(JavaVM *vm, void **penv, void *_args, bool daemon) {
....
....
// Create Java level thread object and attach it to this thread
bool attach_failed = false;
{
EXCEPTION_MARK;
HandleMark hm(THREAD);
Handle thread_group(THREAD, group);
thread->allocate_threadObj(thread_group, thread_name, daemon, THREAD); <--
if (HAS_PENDING_EXCEPTION) {
CLEAR_PENDING_EXCEPTION;
// cleanup outside the handle mark.
attach_failed = true;
}
}
The first parameter passed to allocate_threadObj() , "thread_group" is null
when crash occurred.
This "thread_group" becomes non-null only after VM creation is finished.
We assume there is a way to syncronize this process and not to call AttachCurrentThread while VM creation is not finished.
When starting several applets continuously and "tab browse" feature is enabled in IE,
applets will be launched in each tab.
IE crashes while loading applet and close tabs, but automatically reopens and restart applet.
[Attached reproduce test]
This applet just obtains Java version and display it on IE screen.
1. Save the attached file in local
2. Open Internet Explorer (make sure "Tab browse" feature is enabled)
3. From command prompt, go to the saved file location and run tp.sh
-> It will launch JavaApplet in different tab one by one
-> If unable to reproduce, please add the more lines in tp.sh to increase the number of Applet to be launched
We suspect this is syncronization issue in JavaVM_GetJNIEnv().
deploy/src/plugin/win32/plugin2/common/JavaVM.c.
// Note: locking would be needed in order to make this code 100% correct.
// It's difficult to implement this without another initialization entry
// point called from DllMain. In practice this will be called in a
// sufficiently single threaded fashion when the JVM initialization occurs.
JNIEnv* JavaVM_GetJNIEnv()
{
JNIEnv* env = NULL;
jint res = 0;
if (!initialized) {
if (!InitializeJVM()) {
return NULL;
}
initialized = 1;
}
res = (*jvm)->AttachCurrentThread(jvm, (void**) &env, NULL);
if (res < 0)
return NULL;
return env;
}
While previous Applet launches JVM, it seems like next Applet tries to attach to the launching JVM.
In fact, our customer reported that when they encounter this issue with debug version of JVM, assertion failed in allocate_threadObj(), thread.cpp in hotspot.
void JavaThread::allocate_threadObj(Handle thread_group, char* thread_name, bool daemon, TRAPS) {
assert(thread_group.not_null(), "thread group should be specified") ; <-
And this allocate_threadObj() is called from attach_current_thread() in jni.cpp
static jint attach_current_thread(JavaVM *vm, void **penv, void *_args, bool daemon) {
....
....
// Create Java level thread object and attach it to this thread
bool attach_failed = false;
{
EXCEPTION_MARK;
HandleMark hm(THREAD);
Handle thread_group(THREAD, group);
thread->allocate_threadObj(thread_group, thread_name, daemon, THREAD); <--
if (HAS_PENDING_EXCEPTION) {
CLEAR_PENDING_EXCEPTION;
// cleanup outside the handle mark.
attach_failed = true;
}
}
The first parameter passed to allocate_threadObj() , "thread_group" is null
when crash occurred.
This "thread_group" becomes non-null only after VM creation is finished.
We assume there is a way to syncronize this process and not to call AttachCurrentThread while VM creation is not finished.
- relates to
-
JDK-7044108 NPAPI Java plugin should not crash even when JRE is not available on the system
- Closed
-
JDK-6974402 IE: optimize startup logic on the browser side
- Resolved