[Mono-bugs] [Bug 81856][Min] Changed - Dead Lock with thread abort/locks in signal handlers

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Thu Aug 30 13:27:13 EDT 2007

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


--- shadow/81856	2007-07-16 12:03:27.000000000 -0400
+++ shadow/81856.tmp.19151	2007-08-30 13:27:13.000000000 -0400
@@ -3,20 +3,20 @@
 Version: 1.2
 OS: GNU/Linux [Other]
 OS Details: Etch with mono 1.2.4
 Status: NEW   
 Severity: Unknown
-Priority: Normal
+Priority: Minor
 Component: misc
 AssignedTo: mono-bugs at ximian.com                            
 ReportedBy: james at stev.org               
 QAContact: mono-bugs at ximian.com
 TargetMilestone: ---
-Summary: Dead Lock with mysql
+Summary: Dead Lock with thread abort/locks in signal handlers
 Please fill in this template when reporting a bug, unless you know what you
 are doing.
 Description of Problem:
@@ -326,6 +326,20 @@
         __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, 
       __size = "\002", '\0' <repeats 11 times>,
       __align = 2}}
+------- Additional Comments From lupus at ximian.com  2007-08-30 13:27 -------
+The issue with this test was that inside the signal handler used to
+notify the abort request we took a lock. The same lock was being taken
+by some other thread. Indeed, pthread_mutex_lock is not one of the
+functions that are allowed in a signal handler.
+The fix required quite a bit of work, though luckily Mark did it all:)
+We now can lookup the runtime info we need to know about in the signal
+handler without taking locks.
+There are still a few more cases where we currently take a lock in
+signal handlers (for example by way of QueueUserAPC), but the chances
+of hitting a deadlock in those case is pretty low, still we'll need to
+fix them eventually, so I'm just downgrading the priority of this bug.

More information about the mono-bugs mailing list