harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory Shimansky (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-3639) [drlvm][thread] ManyThreadTest deadlocks
Date Thu, 07 Jun 2007 12:47:26 GMT

    [ 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.


Mime
View raw message