[Mono-bugs] [Bug 76843][Nor] New - Crash in monitor.c:203 (mono_monitor_try_enter_internal)

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Mon Nov 28 20:12:30 EST 2005


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 abockover at novell.com.

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

--- shadow/76843	2005-11-28 20:12:30.000000000 -0500
+++ shadow/76843.tmp.22904	2005-11-28 20:12:30.000000000 -0500
@@ -0,0 +1,79 @@
+Bug#: 76843
+Product: Mono: Runtime
+Version: 1.1
+OS: 
+OS Details: SUSE 10.0
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Normal
+Component: JIT
+AssignedTo: lupus at ximian.com                            
+ReportedBy: abockover at novell.com               
+QAContact: mono-bugs at ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: Crash in monitor.c:203 (mono_monitor_try_enter_internal)
+
+This is a weird crash that I have seen only in Banshee. Specifically, a
+second instance of Banshee where a command is sent over D-Bus to an already
+running instance. The expected behavior is that the second instance will
+send the command and immediately exit. 
+
+The command is sent, the first instance responds appropriately, and then
+the second instance SIGSEGVs in monitor.c:
+
+(gdb) run /usr/lib/banshee/banshee.exe
+Starting program: /usr/bin/mono /usr/lib/banshee/banshee.exe
+[Thread debugging using libthread_db enabled]
+[New Thread 1076079520 (LWP 30622)]
+[New Thread 1073916848 (LWP 30625)]
+[New Thread 1086438320 (LWP 30626)]
+
+Program received signal SIGSEGV, Segmentation fault.
+[Switching to Thread 1086438320 (LWP 30626)]
+mono_monitor_try_enter_internal (obj=0x83117e8, ms=4294967295,
+    allow_interruption=1) at monitor.c:203
+203     monitor.c: No such file or directory.
+        in monitor.c
+
+(gdb) bt
+
+#0  mono_monitor_try_enter_internal (obj=0x83117e8, ms=4294967295,
+    allow_interruption=1) at monitor.c:203
+#1  0x080df853 in ves_icall_System_Threading_Monitor_Monitor_try_enter (
+    obj=0x83117e8, ms=4294967295) at monitor.c:383
+...
+
+(gdb) p mono_print_method_from_ip(0x40e8f369)
+IP 0x40e8f369 at offset 0x29 of method (wrapper managed-to-native)
+System.Threading.Monitor:Monitor_try_enter (object,int) (0x40e8f340
+0x40e8f39c)[domain 0x21f00 - banshee.exe]
+$1 = void
+(gdb)
+
+After #2, nothing else resolves.
+
+Here's the trace without gdb:
+
+in <0x4> (wrapper managed-to-native)
+System.Threading.Monitor:Monitor_try_enter (object,int)
+in <0xffffffb3> (wrapper managed-to-native)
+System.Threading.Monitor:Monitor_try_enter (object,int)
+in [0x13] System.Threading.Monitor:Enter (object)
+in <0xffffffe5> (wrapper synchronized) DBus.Service:remove_SignalCalled
+(DBus.Service/SignalCalledHandler)
+in <0x15> Banshee.BansheeCore.Proxy:Finalize ()
+in <0xc6f58355> (wrapper runtime-invoke) System.Object:runtime_invoke_void
+(object,intptr,intptr,intptr)
+
+I can probably work around this in Banshee, but this still shouldn't happen :)
+
+So to reproduce:
+
+$ banshee &
+$ banshee --play
+
+This is on 1.1.10, I haven't tried from HEAD, but Miguel can reproduce
+this. dbus-sharp 0.5.


More information about the mono-bugs mailing list