[Mono-bugs] [Bug 81654][Nor] New - Deadlock on SMP systems.

[bugzilla-daemon at bugzilla.ximian.com]

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 miguel at ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=81654

--- shadow/81654	2007-05-17 10:07:05.000000000 -0400
+++ shadow/81654.tmp.24013	2007-05-17 10:07:05.000000000 -0400
@@ -0,0 +1,81 @@
+Bug#: 81654
+Product: Mono: Runtime
+Version: 1.2
+OS: 
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Normal
+Component: JIT
+AssignedTo: lupus at ximian.com                            
+ReportedBy: miguel at ximian.com               
+QAContact: mono-bugs at ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: Deadlock on SMP systems.
+
+Inside the SUSE network there is an 8 CPU machine x86-64:
+
+root at titanica.suse.de
+
+Where we have been experiencing some problems when we run the program `rug'
+thousands of times (rug itself does not use threads directly, but it might
+be doing this through the async IO used by the web services backend that
+calls the various BeginXXX methods).
+
+The stack traces on x86-64 are usually ugly, but the deadlock seems to
+happen when the mono_method_to_ir also gets the marshalling lock:
+
+This is from the thread with the clean stack trace:
+
+#3  0x00002b105d3256dd in pthread_mutex_lock () from /lib64/libpthread.so.0
+#4  0x000000000047141e in mono_marshal_get_native_wrapper (method=0x73bff0)
+at marshal.c:2715
+#5  0x00000000004f8ba6 in mono_method_to_ir (cfg=0x2aaaab800d90,
+method=0x739d78, start_bblock=0x2aaaab801130,
+    end_bblock=0x2aaaab801238, locals_offset=2, return_var=0x0,
+dont_inline=0x77e2a8, inline_args=0x0, inline_offset=0,
+    is_virtual_call=0) at mini.c:4564
+#6  0x0000000000502485 in mini_method_compile (method=0x739d78, opts=1,
+domain=<value optimized out>,
+    run_cctors=<value optimized out>, compile_aot=<value optimized out>,
+parts=0) at mini.c:10247
+#7  0x0000000000503cba in mono_jit_compile_method (method=0x739d78) at
+mini.c:10612
+#8  0x000000000043f9c9 in mono_magic_trampoline (regs=0x7fff4dd466f8,
+code=0x11ee <Address 0x11ee out of bounds>, m=0x6,
+    tramp=0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>) at
+mini-trampolines.c:27
+#9  0x000000004000013a in ?? ()
+#10 0x00002aaaab6bc100 in ?? ()
+#11 0x000000000043fad0 in mono_magic_trampoline (regs=<value optimized
+out>, code=0x2aaaab62a708 "HS\200", m=<value optimized out>,
+    tramp=<value optimized out>) at mini-trampolines.c:58
+
+(The top two frames are an abort, as I had to manually get out of the
+__ll_mutex_lock_wait that was hung as it made the stack trace difficult to
+read).
+
+The other stack was harder to get "clean", I could not single step the
+thread (even after manually selecting it with gdb, do not know whY):
+
+Thread 2 (Thread 1078221120 (LWP 4593)):
+#0  0x00002b105d329548 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0
+#1  0x00002b105d32c290 in fmod () from /lib64/libpthread.so.0
+#2  0xffffffffffffffff in ?? ()
+#3  0x00002b105d3258ec in fmod () from /lib64/libpthread.so.0
+#4  0x000000000088c8a0 in ?? ()
+#5  0x00000000007e1ff8 in ?? ()
+#6  0x00000000006f0930 in ?? ()
+#7  0x0000000000887398 in ?? ()
+#8  0x0000000040241dd0 in ?? ()
+#9  0x0000000040241d73 in ?? ()
+#10 0x0000000000710970 in ?? ()
+#11 0x0000000000712dd8 in ?? ()
+#12 0x0000000040241d50 in ?? ()
+#13 0x00002b105d1cf7b9 in g_str_equal () from /opt/gnome/lib64/libglib-2.0.so.0
+#14 0x00000000004e7275 in mono_icall_get_wrapper (callinfo=0x6ccc48) at
+mini.c:7804
+#15 0x0000000000000000 in ?? ()