[Mono-bugs] [Bug 74154][Maj] Changed - Mutex class locks on OS X in simple application
bugzilla-daemon@bugzilla.ximian.com
bugzilla-daemon@bugzilla.ximian.com
Tue, 29 Mar 2005 13:08:36 -0500 (EST)
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=74154
--- shadow/74154 2005-03-28 17:49:51.000000000 -0500
+++ shadow/74154.tmp.8845 2005-03-29 13:08:36.000000000 -0500
@@ -3,15 +3,15 @@
Version: 1.1
OS: unknown
OS Details:
Status: NEW
Resolution:
Severity: Unknown
-Priority: Wishlist
+Priority: Major
Component: io-layer
-AssignedTo: mono-bugs@ximian.com
+AssignedTo: dick@ximian.com
ReportedBy: cgaisford@novell.com
QAContact: mono-bugs@ximian.com
TargetMilestone: ---
URL:
Summary: Mutex class locks on OS X in simple application
@@ -53,6 +53,15 @@
#8 0x000020ec in _start (argc=1, argv=0x4, envp=0x131eb80) at /SourceCache/Csu/
Csu-46/crt.c:267
#9 0x00001f60 in start ()
-kangaroo
+
+------- Additional Comments From lupus@ximian.com 2005-03-29 13:08 -------
+pthread_cond_(timed)wait is supposed to be called after the condition
+has been tested and the condition must be tested afterwards to account
+for races, spurious wakeups etc.
+The backtraces I saw point at a pthread_cod_wait called by
+_wapi_handle_wait_signal_handle in io-layer/handles.c: it doesn't look
+like the pattern of checking the condition before and after (in a
+loop) is followed here and this could be the cause of this bug.