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 [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=81856 --- 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 Resolution: Severity: Unknown -Priority: Normal +Priority: Minor Component: misc AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] QAContact: [EMAIL PROTECTED] TargetMilestone: --- URL: -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>, "\001\000\000\000\000\000\000\000\000\000\000", __align = 2}} + +------- Additional Comments From [EMAIL PROTECTED] 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. + _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
