You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Gregory Shimansky (JIRA)" <ji...@apache.org> on 2007/06/07 14:47:26 UTC
[jira] Commented: (HARMONY-3639) [drlvm][thread] ManyThreadTest
deadlocks
[ https://issues.apache.org/jira/browse/HARMONY-3639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502323 ]
Gregory Shimansky commented on HARMONY-3639:
--------------------------------------------
I can reproduce the bug almost in 100% cases on uniprocessor linux box with HT enabled. Trying to analyze the dead lock it looks like on shutdown the main thread dead locks with ref_enqueue_thread_func thread.
Main thread has the following stack:
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb79abb7c in sched_yield () from /lib/libc.so.6
#2 0xb7a93221 in hythread_yield ()
at /nfs/ims/proj/drl/mrt2/users/gregory/gentoo/trunk/working_vm/vm/thread/src/thread_native_basic.c:328
#3 0xb6bcc1cd in wait_native_ref_thread_detached ()
at /nfs/ims/proj/drl/mrt2/users/gregory/gentoo/trunk/working_vm/vm/vmcore/src/init/ref_enqueue_thread.cpp:92
#4 0xb6bece38 in vm_destroy (java_vm=0x8079740, java_thread=0x8518068)
at /nfs/ims/proj/drl/mrt2/users/gregory/gentoo/trunk/working_vm/vm/vmcore/src/init/vm_shutdown.cpp:190
#5 0xb6b4dc42 in DestroyJavaVM (vm=0x8079740)
at /nfs/ims/proj/drl/mrt2/users/gregory/gentoo/trunk/working_vm/vm/vmcore/src/jni/jni.cpp:1473
#6 0x08049baf in invocation (portLibrary=0xbfb79a0c, argc=6, argv=0xbfb79e54, handle=134655928, version=65540,
ignoreUnrecognized=1 '\001', mainClass=0xbfb7ad41 "thread.ManyThreadsTest", classArg=5,
propertiesFileName=0x806ae88 "/nfs/ims/proj/drl/mrt2/users/gregory/gentoo/trunk/working_vm/build/lnx_ia32_gcc_debug/deploy/jdk/jre/bin/default/harmonyvm.properties", isStandaloneJar=0, vmdllsubdir=0xbfb79936 "default")
at ../shared/main.c:756
#7 0x08049150 in gpProtectedMain (args=0xbfb799ec) at ../shared/main.c:389
#8 0x0804b5e4 in main (argc=6, argv=0xbfb79e54, envp=0xbfb79e70) at ../shared/cmain.c:146
It waits in a loop for the ref thread to finish. But ref thread doesn't finish for some reason. It has the following stack:
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb77e4466 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2 0xb79cdce8 in pthread_cond_wait () from /lib/libc.so.6
#3 0xb7a9188a in os_cond_timedwait (cond=0x8724b48, mutex=0x8724b78, ms=0, nano=0)
at /nfs/ims/proj/drl/mrt2/users/gregory/gentoo/trunk/working_vm/vm/thread/src/linux/os_condvar.c:42
#4 0xb7a93d37 in condvar_wait_impl (cond=0x8724b48, mutex=0x8724b78, ms=0, nano=0, interruptable=0)
at /nfs/ims/proj/drl/mrt2/users/gregory/gentoo/trunk/working_vm/vm/thread/src/thread_native_condvar.c:55
#5 0xb7a95887 in sem_wait_impl (sem=0x8724b40, ms=0, nano=0, interruptable=0)
at /nfs/ims/proj/drl/mrt2/users/gregory/gentoo/trunk/working_vm/vm/thread/src/thread_native_semaphore.c:70
#6 0xb7a95983 in hysem_wait (sem=0x8724b40)
at /nfs/ims/proj/drl/mrt2/users/gregory/gentoo/trunk/working_vm/vm/thread/src/thread_native_semaphore.c:107
#7 0xb6bcc3d4 in wait_pending_reference ()
at /nfs/ims/proj/drl/mrt2/users/gregory/gentoo/trunk/working_vm/vm/vmcore/src/init/ref_enqueue_thread.cpp:126
#8 0xb6bcc4fb in ref_enqueue_thread_func (args=0x87160a8)
at /nfs/ims/proj/drl/mrt2/users/gregory/gentoo/trunk/working_vm/vm/vmcore/src/init/ref_enqueue_thread.cpp:149
#9 0xb7a93b1d in thread_start_proc (arg=0x8724d68)
at /nfs/ims/proj/drl/mrt2/users/gregory/gentoo/trunk/working_vm/vm/thread/src/thread_native_basic.c:711
#10 0xb77e02c1 in start_thread () from /lib/libpthread.so.0
#11 0xb79c2fae in clone () from /lib/libc.so.6
What it is waiting for, and why it doesn't finish I don't know. On multiprocessors box the test doesn't hang often, but hangs as well. On 4 CPU box it hanged for me after 300 iterations.
I am going to exclude the test on Linux until the bug is fixed.
> [drlvm][thread] ManyThreadTest deadlocks
> ----------------------------------------
>
> Key: HARMONY-3639
> URL: https://issues.apache.org/jira/browse/HARMONY-3639
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Reporter: Peter Novodvorsky
> Priority: Minor
>
> ManyThreadsTest from HARMONY-2742 sometimes hangs on 4996 iteration, backtrace shows that it hangs in compiler:
> (gdb) thread 1
> [Switching to thread 1 (Thread 1080397952 (LWP 22821))]#0 0xffffe410 in ?? ()
> (gdb) thread 0
> Thread ID 0 not known.
> (gdb) where
> #0 0xffffe410 in ?? ()
> #1 0xbfffc7b4 in ?? ()
> #2 0x00000002 in ?? ()
> #3 0x00000000 in ?? ()
> #4 0x40652efe in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0
> #5 0x4064fc6c in _L_mutex_lock_88 () from /lib/tls/libpthread.so.0
> #6 0x00000ff4 in ?? ()
> #7 0xbfffc7c4 in ?? ()
> #8 0x40552bf8 in __elf_set___libc_thread_subfreeres_element___rpc_thread_destroy__ () from /lib/tls/libc.so.6
> #9 0xb7b1de00 in ?? ()
> #10 0x423db324 in ?? ()
> #11 0xbfffc7c4 in ?? ()
> #12 0x4050435a in pthread_mutex_lock () from /lib/tls/libc.so.6
> #13 0x4050435a in pthread_mutex_lock () from /lib/tls/libc.so.6
> #14 0x41c7a6a0 in Jitrino::Mutex::lock (this=0x41f71a28) at mkernel.h:111
> #15 0x41c7e324 in Jitrino::CompilationInterface::lockMethodData (
> this=0xbfffc9cc)
> at /localdisk/users/panovodv/harmony/tree/trunk/working_vm/vm/jitrino/src/vm/drl/DrlVMInterface.cpp:873
> #16 0x41d8b316 in Jitrino::LockMethodSessionAction::run (this=0xb7b43f0c)
> at /localdisk/users/panovodv/harmony/tree/trunk/working_vm/vm/jitrino/src/main/Jitrino.cpp:197
> ---Type <return> to continue, or q <return> to quit---q
> Quit
> (gdb) thread 2
> [Switching to thread 2 (Thread -1818022992 (LWP 27816))]#0 0xffffe410 in ?? ()
> (gdb) where
> #0 0xffffe410 in ?? ()
> #1 0x93a313b4 in ?? ()
> #2 0x93a32bb0 in ?? ()
> #3 0x8d36be30 in ?? ()
> #4 0x404e307c in sched_yield () from /lib/tls/libc.so.6
> #5 0x4001fe18 in hythread_yield ()
> at /localdisk/users/panovodv/harmony/tree/trunk/working_vm/vm/thread/src/thread_native_basic.c:330
> #6 0x40bca40f in jthread_monitor_enter (monitor=0x89658f0)
> at /localdisk/users/panovodv/harmony/tree/trunk/working_vm/vm/thread/src/thread_java_monitors.c:131
> #7 0x4194c5de in ?? ()
> #8 0x089658f0 in ?? ()
> #9 0x93a325c8 in ?? ()
> #10 0xb036d5d0 in ?? ()
> #11 0x089658e8 in ?? ()
> #12 0x00000000 in ?? ()
> #13 0x00000000 in ?? ()
> #14 0x00000000 in ?? ()
> #15 0xdeadbeef in ?? ()
> #16 0xdeadbeef in ?? ()
> #17 0x423dbfe4 in ?? ()
> #18 0x93a3152c in ?? ()
> ---Type <return> to continue, or q <return> to quit---q
> Quit
> (gdb) thread 3
> [Switching to thread 3 (Thread 1389202352 (LWP 22824))]#0 0xffffe410 in ?? ()
> (gdb) where
> #0 0xffffe410 in ?? ()
> #1 0x52cd81cc in ?? ()
> #2 0x0000001b in ?? ()
> #3 0x00000000 in ?? ()
> #4 0x40650896 in pthread_cond_wait@@GLIBC_2.3.2 ()
> from /lib/tls/libpthread.so.0
> #5 0x405041b3 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libc.so.6
> #6 0x4001e882 in os_cond_timedwait (cond=0x52d03448, mutex=0x52d03430, ms=0,
> nano=0)
> at /localdisk/users/panovodv/harmony/tree/trunk/working_vm/vm/thread/src/linux/os_condvar.c:41
> #7 0x400207d1 in condvar_wait_impl (cond=0x52d03448, mutex=0x52d03430, ms=0,
> nano=0, interruptable=1)
> at /localdisk/users/panovodv/harmony/tree/trunk/working_vm/vm/thread/src/thread_native_condvar.c:55
> #8 0x40020cb2 in monitor_wait_impl (mon_ptr=0x52d03430, ms=0, nano=0,
> interruptable=1)
> at /localdisk/users/panovodv/harmony/tree/trunk/working_vm/vm/thread/src/thread_native_fat_monitor.c:189
> #9 0x400231db in thin_monitor_wait_impl (lockword_ptr=0x4240b284, ms=0,
> nano=0, interruptable=1)
> at /localdisk/users/panovodv/harmony/tree/trunk/working_vm/vm/thread/src/thread_native_thin_monitor.c:439
> ...
> Java stack is:
> The stack trace of the 0xb036d500 java thread:
> [0xb036d500] 0x52abbc8d(m): java/security/AccessController.getContext()Ljava/security/AccessControlContext;
> [0xb036d500] 0x52ac2972(m): java/lang/Thread.<init>(Ljava/lang/ThreadGroup;Ljava/lang/Runnable;Ljava/lang/String;J)V
> [0xb036d500] 0x52ac2390(m): java/lang/Thread.<init>(Ljava/lang/ThreadGroup;Ljava/lang/String;)V
> [0xb036d500] 0x52ac220d(m): java/lang/FinalizerThread.<init>(Z)V
> [0xb036d500] 0x52e2826c(m): java/lang/FinalizerThread.spawnBalanceThreads()V
> [0xb036d500] 0x52e27e32(m): java/lang/FinalizerThread.startFinalization(Z)V
> [0xb036d500] 0x52ac4bf3(m): java/lang/Object.notifyAll()V
> [0xb036d500] 0x52e26e75(m): java/lang/Thread.detach(Ljava/lang/Throwable;)V
> The stack trace of the 0x86ee978 java thread:
> [0x86ee978] (nil)(n): java/lang/VMThreadManager.wait(Ljava/lang/Object;JI)I
> [0x86ee978] 0x52ac46b1(m): java/lang/Object.wait()V
> [0x86ee978] 0x52ac6eae(m): java/lang/FinalizerThread.waitNewTask()V
> [0x86ee978] 0x52ac5c3d(m): java/lang/FinalizerThread.run()V
> [0x86ee978] 0x52ac4b3e(m): java/lang/Thread.runImpl()V
> The stack trace of the 0x80ba680 java thread:
> [0x80ba680] 0x52ac32ad(m): java/util/WeakHashMap.get(Ljava/lang/Object;)Ljava/lang/Object;
> [0x80ba680] 0x52abbcbb(m): java/security/AccessController.getContext()Ljava/security/AccessControlContext;
> [0x80ba680] 0x52ac2972(m): java/lang/Thread.<init>(Ljava/lang/ThreadGroup;Ljava/lang/Runnable;Ljava/lang/String;J)V
> [0x80ba680] 0x52e261af(m): java/lang/Thread.<init>(Ljava/lang/Runnable;)V
> [0x80ba680] 0x52ac84d8(m): ManyThreadsTest.main([Ljava/lang/String;)V
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.