[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.