You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "weldon washburn (JIRA)" <ji...@apache.org> on 2007/05/18 07:35:17 UTC
[jira] Commented: (HARMONY-3314) [drlvm][shutdown][thread] DRLVM
hangs on exit while detaching thread
[ https://issues.apache.org/jira/browse/HARMONY-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496783 ]
weldon washburn commented on HARMONY-3314:
------------------------------------------
I ran the following on my windows laptop. The "timeout=99..." allows time to attach the MSVC debugger. After about 20 minutes, the VMDeathTest was hung.
:THETOP
deploy\jdk\bin\java -Djpda.settings.timeout=99999999999 -classpath ..\common_resources\depends\jars\junit_3.8.2\junit.jar;build\tests\classes org.apache.harmony.jpda.tests.jdwp.Events.VMDeathTest
GOTO THETOP
Using the MSVC debugger, I noticed there are three (3) different java.exe's running. The java.exe that looks like the hung JVM that needs fixing shows there are four threads doing the following:
1)
This thread is executes a jdwp::PacketDispatcher::ShutdownAll() which calls PacketDispatcher::Stop() and Stop() is blocked on m_monitor=14 (owning thread = 8904, thread #4).
2)
A gcv5 collector thread waiting waiting for a gc request (not particularly interesting)
3)
This thread is thread waiting for jdwp::EventDispatcher::Run() waiting at m_eventQueue.empty(). That is waiting for a message that says, "do something" (Not particularly interesting)
4)
This thread calls jdwp::EventDispatcher::Stop() which in turn called jdwp::AgentMonitor::Enter() which in turn is blocked trying to grab m_monitor=13 (owning thread = 6024, thread 3)
It seems that somehow thread #3 is accidentally holding m_monitor=13 while it is waiting for an event to happen?? Does anyone else see this?
The call stack for thread #1 above looks like:
ntdll.dll!7c90eb94()
ntdll.dll!7c90e9c0()
ntdll.dll!7c91901b()
ntdll.dll!7c91056d()
> msvcr71d.dll!_free_base(void * pBlock=0x00070338) Line 103 C
ntdll.dll!7c90104b()
hythr.dll!hymutex_lock(_RTL_CRITICAL_SECTION * mutex=0x03070338) Line 63 + 0xc C
hythr.dll!hythread_monitor_enter(HyThreadMonitor * mon_ptr=0x03070338) Line 88 + 0x9 C
harmonyvm.dll!jthread_raw_monitor_enter(int mon_ptr=14) Line 116 + 0x9 C
harmonyvm.dll!jvmtiRawMonitorEnter(jvmtiEnv_struct * env=0x011eb3f0, int monitor=14) Line 91 + 0x9 C++
jdwp.dll!jvmtiEnv_struct::RawMonitorEnter(int monitor=14) Line 1227 C++
jdwp.dll!jdwp::AgentMonitor::Enter() Line 47 + 0x12 C++
jdwp.dll!jdwp::MonitorAutoLock::MonitorAutoLock(jdwp::AgentMonitor * monitor=0x025fdee0, const char * file=0x1327c114, int line=235) Line 123 C++
jdwp.dll!jdwp::PacketDispatcher::Stop() Line 236 C++
jdwp.dll!jdwp::PacketDispatcher::ShutdownAll(JNIEnv_External * jni=0x011e9590) Line 310 C++
jdwp.dll!VMDeath(jvmtiEnv_struct * jvmti=0x011eb3f0, JNIEnv_External * jni=0x011e9590) Line 179 + 0x10 C++
harmonyvm.dll!jvmti_send_vm_death_event() Line 2116 + 0xd C++
harmonyvm.dll!vm_destroy(JavaVM_Internal * java_vm=0x01182d58, _jobject * java_thread=0x025d1a88) Line 205 C++
harmonyvm.dll!DestroyJavaVM(JavaVM_External * vm=0x01182d58) Line 1473 + 0xd C++
java.exe!invocation(HyPortLibrary * portLibrary=0x0013fbc0, int argc=7, char * * argv=0x00412fa8, unsigned int handle=4325376, int version=65540, unsigned char ignoreUnrecognized=' ', char * mainClass=0x00412e2b, unsigned int classArg=6, char * propertiesFileName=0x0015c000, int isStandaloneJar=0, char * vmdllsubdir=0x0013faf0) Line 729 C
java.exe!gpProtectedMain(haCmdlineOptions * args=0x0013fb98) Line 362 + 0x33 C
java.exe!signalProtectedMain(HyPortLibrary * portLibrary=0x0013fbc0, void * arg=0x0013fb98) Line 80 + 0x9 C
hyprt.dll!hysig_protect(HyPortLibrary * portLibrary=0x0013fbc0, unsigned int (HyPortLibrary *, void *)* fn=0x00401260, void * fn_arg=0x0013fb98, unsigned int (HyPortLibrary *, unsigned int, void *, void *)* handler=0x004010f0, void * handler_arg=0x00000000, unsigned int flags=124, unsigned int * result=0x0013fb94) Line 130 + 0xb C
java.exe!main(int argc=7, char * * argv=0x00412fa8, char * * envp=0x00413658) Line 109 + 0x29 C
java.exe!mainCRTStartup() Line 398 + 0x11 C
kernel32.dll!7c816fd7()
harmonyvm.dll!EncoderBase::Operand::is_mem() Line 412 + 0x18 C++
The call stack for #2 thread looks like:
ntdll.dll!7c90eb94()
ntdll.dll!7c90e9c0()
kernel32.dll!7c8025cb()
kernel32.dll!7c8307ff()
kernel32.dll!7c802532()
> hythr.dll!os_cond_timedwait(HyCond * cond=0x003e22f0, _RTL_CRITICAL_SECTION * mutex=0x003e2314, __int64 ms=0, int nano=0) Line 89 + 0x10 C
hythr.dll!condvar_wait_impl(HyCond * cond=0x003e22f0, _RTL_CRITICAL_SECTION * mutex=0x003e2314, __int64 ms=0, int nano=0, int interruptable=0) Line 55 + 0x19 C
hythr.dll!sem_wait_impl(HySemaphore * sem=0x003e22e8, __int64 ms=0, int nano=0, int interruptable=0) Line 70 + 0x23 C
hythr.dll!hysem_wait(HySemaphore * sem=0x003e22e8) Line 107 + 0x11 C
gc_gen.dll!vm_wait_event(HySemaphore * event=0x003e22e8) Line 68 + 0x14 C++
gc_gen.dll!collector_wait_for_task(Collector * collector=0x00415a48) Line 101 + 0xc C++
gc_gen.dll!collector_thread_func(void * arg=0x00415a48) Line 150 + 0x9 C++
hythr.dll!thread_start_proc(void * arg=0x003e2598) Line 711 + 0x9 C
hythr.dll!_threadstartex(void * ptd=0x003efb90) Line 241 + 0xd C
kernel32.dll!7c80b683()
The call stack for #3 looks like:
ntdll.dll!7c90eb94()
ntdll.dll!7c90e9c0()
kernel32.dll!7c8025cb()
ntdll.dll!7c960bcc()
kernel32.dll!7c8307ff()
kernel32.dll!7c802532()
> hythr.dll!os_cond_timedwait(HyCond * cond=0x03070110, _RTL_CRITICAL_SECTION * mutex=0x030700f8, __int64 ms=0, int nano=0) Line 89 + 0x10 C
hythr.dll!condvar_wait_impl(HyCond * cond=0x03070110, _RTL_CRITICAL_SECTION * mutex=0x030700f8, __int64 ms=0, int nano=0, int interruptable=1) Line 55 + 0x19 C
hythr.dll!monitor_wait_impl(HyThreadMonitor * mon_ptr=0x030700f8, __int64 ms=0, int nano=0, int interruptable=1) Line 189 + 0x20 C
hythr.dll!hythread_monitor_wait_interruptable(HyThreadMonitor * mon_ptr=0x030700f8, __int64 ms=0, int nano=0) Line 296 + 0x17 C
harmonyvm.dll!jthread_raw_monitor_wait(int mon_ptr=10, __int64 millis=0) Line 181 + 0x13 C
harmonyvm.dll!jvmtiRawMonitorWait(jvmtiEnv_struct * env=0x011eb3f0, int monitor=10, __int64 millis=0) Line 120 + 0x11 C++
jdwp.dll!jvmtiEnv_struct::RawMonitorWait(int monitor=10, __int64 millis=0) Line 1237 C++
jdwp.dll!jdwp::AgentMonitor::Wait(__int64 timeout=0) Line 55 + 0xc1 C++
jdwp.dll!jdwp::EventDispatcher::Run(JNIEnv_External * jni=0x025febe0) Line 60 C++
jdwp.dll!jdwp::EventDispatcher::StartFunction(jvmtiEnv_struct * jvmti=0x011eb3f0, JNIEnv_External * jni=0x025febe0, void * arg=0x011f3a60) Line 96 C++
harmonyvm.dll!wrapper_proc(void * arg=0x025fb0d8) Line 99 + 0x1a C
hythr.dll!thread_start_proc(void * arg=0x003e28b0) Line 711 + 0x9 C
hythr.dll!_threadstartex(void * ptd=0x03070968) Line 241 + 0xd C
kernel32.dll!7c80b683()
The call stack for #4 thread looks like:
ntdll.dll!7c90eb94()
ntdll.dll!7c90e9c0()
ntdll.dll!7c91901b()
ntdll.dll!7c91056d()
> msvcr71d.dll!_free_base(void * pBlock=0x000702a8) Line 103 C
ntdll.dll!7c90104b()
hythr.dll!hymutex_lock(_RTL_CRITICAL_SECTION * mutex=0x030702a8) Line 63 + 0xc C
hythr.dll!hythread_monitor_enter(HyThreadMonitor * mon_ptr=0x030702a8) Line 88 + 0x9 C
harmonyvm.dll!jthread_raw_monitor_enter(int mon_ptr=13) Line 116 + 0x9 C
harmonyvm.dll!jvmtiRawMonitorEnter(jvmtiEnv_struct * env=0x011eb3f0, int monitor=13) Line 91 + 0x9 C++
jdwp.dll!jvmtiEnv_struct::RawMonitorEnter(int monitor=13) Line 1227 C++
jdwp.dll!jdwp::AgentMonitor::Enter() Line 47 + 0x12 C++
jdwp.dll!jdwp::MonitorAutoLock::MonitorAutoLock(jdwp::AgentMonitor * monitor=0x025fdeb0, const char * file=0x1327abec, int line=164) Line 123 C++
jdwp.dll!jdwp::EventDispatcher::Stop(JNIEnv_External * jni=0x02602d38) Line 165 C++
jdwp.dll!jdwp::PacketDispatcher::Run(JNIEnv_External * jni=0x02602d38) Line 203 + 0x10 C++
jdwp.dll!jdwp::PacketDispatcher::StartFunction(jvmtiEnv_struct * jvmti_env=0x011eb3f0, JNIEnv_External * jni=0x02602d38, void * arg=0x011f39b8) Line 332 C++
harmonyvm.dll!wrapper_proc(void * arg=0x02600af8) Line 99 + 0x1a C
hythr.dll!thread_start_proc(void * arg=0x003e2f00) Line 711 + 0x9 C
hythr.dll!_threadstartex(void * ptd=0x03070628) Line 241 + 0xd C
kernel32.dll!7c80b683()
> [drlvm][shutdown][thread] DRLVM hangs on exit while detaching thread
> --------------------------------------------------------------------
>
> Key: HARMONY-3314
> URL: https://issues.apache.org/jira/browse/HARMONY-3314
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM, JDK
> Environment: Linux/ia32, Windows/ia32, Harmony-jdk-r514598, Harmony-jdk-r533073
> Reporter: Ivan Popov
> Assigned To: weldon washburn
>
> Many JDWP tests run long time on Linux because DRLVM intermittently crashed at exit.
> For example, the following test
> org.apache.harmony.jpda.tests.jdwp.Events.VMDeathTest
> Here is typical diagnostics in the test output:
> Waiting for debuggee exit
> STDERR> SIGSEGV in VM code.
> STDERR> Stack trace:
> STDERR> 1: ?? (??:-1)
> STDERR> addr2line: '[heap]': No such file
> Ignoring exception in ProcessWaiter thread interrupted: java.lang.InterruptedException
> # ERROR: Enforced debuggee termination
> To reproduce this failure:
> 1. create Harmony JDK with federated build:
> svn checkout https://svn.apache.org/repos/asf/harmony/enhanced/trunk
> cd trunk
> ant
> 2. goto jdktools directory, add junit to classpath, and run particular test:
> cd working_jdktools
> export CLASSPATH=<...>/trunk/common_resources/depends/jars/junit_3.8.2/junit.jar
> ant test -Dbuild.module=jpda -Dtest.case=org.apache.harmony.jpda.tests.jdwp.Events.VMDeathTest
> 3. see results in <...>/trunk/working_jdktools/build/test_report/html/index.html
> It is possible also to run test directly from command line:
> cd working_jdktools
> deploy/jdk/bin/java -classpath ../common_resources/depends/jars/junit_3.8.2/junit.jar:build/tests/classes \
> org.apache.harmony.jpda.tests.jdwp.Events.VMDeathTest
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.