[Mono-bugs] [Bug 58706][Nor] New - deadlocks on SMP
bugzilla-daemon@bugzilla.ximian.com
bugzilla-daemon@bugzilla.ximian.com
Wed, 19 May 2004 11:49:31 -0400 (EDT)
Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.
Changed by lupus@ximian.com.
http://bugzilla.ximian.com/show_bug.cgi?id=58706
--- shadow/58706 2004-05-19 11:49:31.000000000 -0400
+++ shadow/58706.tmp.7560 2004-05-19 11:49:31.000000000 -0400
@@ -0,0 +1,120 @@
+Bug#: 58706
+Product: Mono: Runtime
+Version: unspecified
+OS:
+OS Details:
+Status: NEW
+Resolution:
+Severity:
+Priority: Normal
+Component: misc
+AssignedTo: mono-bugs@ximian.com
+ReportedBy: lupus@ximian.com
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL:
+Cc:
+Summary: deadlocks on SMP
+
+This deadlocks happen on a SMP G5 box, but they could likely happen on any
+SMP box.
+The first happens when the finalizer thread is signalled. Here is the
+backtrace:
+0x90018ce8 in semaphore_timedwait_signal_trap ()
+(gdb) t a a bt
+
+Thread 3 (process 26651 thread 0x2403):
+#0 0xffff8268 in __spin_lock ()
+#1 0x900021a0 in pthread_mutex_lock ()
+#2 0x010ab498 in SetEvent (handle=0x3) at
+../../mono/io-layer/handles-private.h:354
+#3 0x010c889c in GC_generic_malloc (lb=1254, k=1) at malloc.c:188
+#4 0x010c8b44 in GC_malloc (lb=1) at malloc.c:311
+#5 0x0105f2a8 in mono_array_new_specific (vtable=0x4e6, n=18081964) at
+object.c:1565
+#6 0x000fe778 in ?? ()
+#7 0x0224dfe0 in ?? ()
+#8 0x000fda20 in ?? ()
+#9 0x0105c284 in mono_runtime_class_init (vtable=0x154) at object.c:201
+#10 0x0101e3dc in mono_jit_compile_method_inner (method=0x3d2ba0,
+target_domain=0x3bf18) at mini.c:8043
+#11 0x0104b620 in ppc_magic_trampoline (method=0x3bf18, code=0x3d22a0,
+sp=0x3bf1c "") at tramp-ppc.c:106
+#12 0x0180bf14 in ?? ()
+#13 0x017fb5a4 in ?? ()
+#14 0x017fb074 in ?? ()
+#15 0x007cf540 in ?? ()
+#16 0x000fe878 in ?? ()
+#17 0x000fd918 in ?? ()
+#18 0x0105e678 in mono_runtime_exec_main (method=0x33fbc0, args=0x47e10,
+exc=0x0) at object.c:1446
+#19 0x0105e2cc in mono_runtime_run_main (method=0x33fbc0, argc=13,
+argv=0xbffff9c8, exc=0x0) at object.c:1319
+#20 0x0107b960 in start_wrapper (data=0x1820600) at threads.c:239
+#21 0x010b8b08 in timed_thread_start_routine (args=0x33ee90) at
+timed-thread.c:129
+#22 0x900247e8 in _pthread_body ()
+
+Thread 2 (process 26651 thread 0x1103):
+#0 0x90014628 in semaphore_wait_trap ()
+#1 0x90002370 in pthread_mutex_lock ()
+#2 0x9000e924 in _pthread_cond_wait ()
+#3 0x010adb30 in _wapi_handle_wait_signal_handle (handle=0x0) at
+handles.c:1510
+#4 0x010b9224 in WaitForSingleObject (handle=0x3, timeout=4294967295) at
+wait.c:99
+#5 0x0106f98c in finalizer_thread (unused=0x0) at gc.c:530
+#6 0x0107b960 in start_wrapper (data=0x1811600) at threads.c:239
+#7 0x010b8b08 in timed_thread_start_routine (args=0x332550) at
+timed-thread.c:129
+#8 0x900247e8 in _pthread_body ()
+
+Thread 1 (process 26651 thread 0x50b):
+#0 0x90018ce8 in semaphore_timedwait_signal_trap ()
+#1 0x9000e888 in _pthread_cond_wait ()
+#2 0x010adb30 in _wapi_handle_wait_signal_handle (handle=0x1403) at
+handles.c:1510
+#3 0x010b9224 in WaitForSingleObject (handle=0x8, timeout=258) at wait.c:99
+#4 0x010b96b0 in WaitForMultipleObjects (numobjects=1, handles=0x0,
+waitall=1, timeout=4294967295) at wait.c:387
+#5 0x0107c6c0 in wait_for_tids (wait=0x0, timeout=99933000) at threads.c:1097
+#6 0x0107c93c in mono_thread_manage () at threads.c:1229
+#7 0x0103bd64 in mono_main (argc=15, argv=0xbffff9c0) at driver.c:800
+#8 0x00001b10 in _start (argc=3356416, argv=0xe, envp=0x4) at
+/SourceCache/Csu/Csu-47/crt.c:267
+#9 0x8fe1a58c in __dyld__dyld_start ()
+
+The other one happens when the runtime shuts down:
+(gdb) t a a bt
+
+Thread 2 (process 26518 thread 0x1103):
+#0 0x90018ce8 in semaphore_timedwait_signal_trap ()
+#1 0x9000e888 in _pthread_cond_wait ()
+#2 0x010adb30 in _wapi_handle_wait_signal_handle (handle=0x1403) at
+handles.c:1510
+#3 0x010b9224 in WaitForSingleObject (handle=0x3, timeout=258) at wait.c:99
+#4 0x0106f98c in finalizer_thread (unused=0x31) at gc.c:530
+#5 0x0107b960 in start_wrapper (data=0x1811600) at threads.c:239
+#6 0x010b8b08 in timed_thread_start_routine (args=0x332600) at
+timed-thread.c:129
+#7 0x900247e8 in _pthread_body ()
+
+Thread 1 (process 26518 thread 0x50b):
+#0 0x90018ce8 in semaphore_timedwait_signal_trap ()
+#1 0x9000e888 in _pthread_cond_wait ()
+#2 0x010adb30 in _wapi_handle_wait_signal_handle (handle=0x1203) at
+handles.c:1510
+#3 0x010b9224 in WaitForSingleObject (handle=0x8, timeout=258) at wait.c:99
+#4 0x010b96b0 in WaitForMultipleObjects (numobjects=1, handles=0x0,
+waitall=1, timeout=4294967295) at wait.c:387
+#5 0x0107c6c0 in wait_for_tids (wait=0x0, timeout=99978000) at threads.c:1097
+#6 0x0107c93c in mono_thread_manage () at threads.c:1229
+#7 0x0103bd64 in mono_main (argc=14, argv=0xbffff9c4) at driver.c:800
+#8 0x00001b10 in _start (argc=3356592, argv=0xd, envp=0x4) at
+/SourceCache/Csu/Csu-47/crt.c:267
+#9 0x8fe1a58c in __dyld__dyld_start ()
+
+In this case it looks like the threads hashtable still contains an entry
+for the thread, but the thread already disappeared (note it doesn't show up
+in the backtrace from gdb: only the current and the finalizer thread are
+there).