harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evgueni Brevnov (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-2306) [drlvm][jvmti] VM crashes if j.l.Thread is instrumented by JVMTI profiler
Date Fri, 24 Nov 2006 15:03:03 GMT
    [ http://issues.apache.org/jira/browse/HARMONY-2306?page=comments#action_12452468 ] 
            
Evgueni Brevnov commented on HARMONY-2306:
------------------------------------------

I'll try to describe the problem in few words. Before calling DestroyJavaVM the launcher detaches
the main thread. So DestroyJavaVM tries to attach the thread before doing cleanup work. Attaching
process involves creation of j.l.Thread instance which is patched by that time. The patched
constructor of j.l.Thread calls jvmtiGetCurrentThreadCpuTime which tries to get j.l.Thread
instance for the current thread.. Ups...

The just_a_workaround.patch containes is the quick fix for the problem. It changes the launcher
so it doesn't detach the main thread before calling DestroyJavaVM.

More investigation is required to identify the root cause. Could JVMTI guys look into this
as well.?!

Thanks
Evgueni

> [drlvm][jvmti] VM crashes if j.l.Thread is instrumented by JVMTI profiler
> -------------------------------------------------------------------------
>
>                 Key: HARMONY-2306
>                 URL: http://issues.apache.org/jira/browse/HARMONY-2306
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM, App-Oriented Bug Reports
>         Environment: Windows/ia32, Linux/ia32
>            Reporter: Ivan Popov
>         Attachments: just_a_workaround.patch, ThreadEventsTest.zip
>
>
> After applying fix for HARMONY-2200 to DRLVM (r475994), it appeared work well with instrumented
HelloWorld class. But now it crashes if profiler instruments system class java/lang/Thread.

> With debug build of DRLVM assertion is thrown:
>   .../vm/thread/src/thread_ti_timing.c:63: jthread_get_thread_cpu_time: Assertion `java_thread'
failed
> Here is typical stack trace from the VC++ debugger:
> >	harmonyvm.dll!GetObjectClass(JNIEnv_External * env=0x010177e8, _jobject * obj=0x00000000)
 Line 1052 + 0x4	C++
>  	harmonyvm.dll!vm_jthread_get_tm_data(_jobject * thread=0x00000000)  Line 189	C++
>  	harmonyvm.dll!jthread_get_thread_cpu_time(_jobject * java_thread=0x00000000, __int64
* nanos_ptr=0x0013f428)  Line 67	C
>  	harmonyvm.dll!jvmtiGetCurrentThreadCpuTime(jvmtiEnv_struct * env=0x00000004, __int64
* nanos_ptr=0x0013f428)  Line 113 + 0xc	C++
>  	ThreadEvents.dll!01c1162a() 	
>  	ThreadEvents.dll!01c11039() 	
>  	interpreter.dll!invokeJNI(unsigned int * args=0x0013f460, int sz=4, void (void)* f=0x01c11000)
 Line 50	C++
>  	interpreter.dll!interpreterInvokeStaticNative(StackFrame & prevFrame={...}, StackFrame
& frame={...}, Method * method=0x01ec5420)  Line 354	C++
>  	interpreter.dll!interpreterInvokeStatic(StackFrame & prevFrame={...}, Method *
method=0x01ec5420)  Line 3334	C++
>  	interpreter.dll!Opcode_INVOKESTATIC(StackFrame & frame={...})  Line 2093 + 0x6
C++
>  	interpreter.dll!interpreter(StackFrame & frame={...})  Line 2880	C++
>  	interpreter.dll!interpreterInvokeStatic(StackFrame & prevFrame={...}, Method *
method=0x01ec55b8)  Line 3285	C++
>  	interpreter.dll!Opcode_INVOKESTATIC(StackFrame & frame={...})  Line 2093 + 0x6
C++
>  	interpreter.dll!interpreter(StackFrame & frame={...})  Line 2880	C++
>  	interpreter.dll!interpreter_execute_method(Method * method=0x01e6f430, jvalue * return_value=0x00000000,
jvalue * args=0x0013f9f8)  Line 3188	C++
>  	interpreter.dll!JIT_execute_method(void * jh=0x00000000, _jmethodID * m=0x01e6f430,
jvalue * return_value=0x00000000, jvalue * args=0x0013f9f8)  Line 162 + 0x14	C++
>  	em.dll!DrlEMImpl::executeMethod(_jmethodID * meth=0x01e6f430, jvalue * return_value=0x00000000,
jvalue * args=0x0013f9f8)  Line 489 + 0x14	C++
>  	em.dll!ExecuteMethod(_jmethodID * meth=0x01e6f430, jvalue * return_value=0x00000000,
jvalue * args=0x0013f9f8)  Line 44	C++
>  	harmonyvm.dll!vm_execute_java_method_array(_jmethodID * method=0x01e6f430, jvalue *
result=0x00000000, jvalue * args=0x0013f9f8)  Line 51 + 0x19	C++
>  	harmonyvm.dll!vm_create_jthread(_jobject * * thread_object=0x0013fa70, JNIEnv_External
* jni_env=0x01fe9360, _jobject * group=0x00000000, char * name=0x0013f3c8, unsigned char daemon=0)
 Line 556 + 0x1e	C++
>  	harmonyvm.dll!vm_attach_internal(JNIEnv_External * * p_jni_env=0x0013fa74, _jobject
* * java_thread=0x0013fa70, JavaVM_External * java_vm=0x00fc20a0, _jobject * group=0x00000000,
char * name=0x0069250c, unsigned char daemon=0)  Line 595 + 0x1c	C++
>  	harmonyvm.dll!DestroyJavaVM(JavaVM_External * vm=0x00fc20a0)  Line 1450 + 0x19	C++
>  	java.exe!00402527() 	
>  	java.exe!00402b82() 	
>  	java.exe!0040111a() 	
>  	hyprt.dll!11105ed8() 	
>  	java.exe!004011ae() 	
> To reproduce this problem run attached test with simple JVMTI agent that replaces java/lang/Thread
class with the instrumented version (found in classes-instr directory). Test archive also
includes javap-disassembled bytecodes of these classes to see the difference.
> In reference VMs (Sun and JRockit) instrumenting their system class java/lang/Thread
in the same way works well. 
> PLEASE NOTE, this test cannot be applied to Sun or JRockit JREs, because it requires
instrumented version of their internal implementation of java/lang/Thread. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message