[Mono-bugs] [Bug 61418][Nor] New - timed-thread destroy/exit problem on G4 / OSX

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Sun, 11 Jul 2004 21:40:43 -0400 (EDT)

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 grompf@sublimeintervention.com.


--- shadow/61418	2004-07-11 21:40:43.000000000 -0400
+++ shadow/61418.tmp.15962	2004-07-11 21:40:43.000000000 -0400
@@ -0,0 +1,66 @@
+Bug#: 61418
+Product: Mono: Runtime
+Version: unspecified
+OS Details: G4 OSX 10.3.4 
+Status: NEW   
+Priority: Normal
+Component: misc
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: grompf@sublimeintervention.com               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+Summary: timed-thread destroy/exit problem on G4 / OSX
+It appears there is a thread race / misordering condition of very small code executed on 10.3.4 
+OSX (only on G4 as far as I can determine).  Small programs; like those in mono/tests will fail 
+** ERROR **: file timed-thread.c: line 69 (_wapi_timed_thread_exit): assertion failed: (thr_ret == 
+The following script will exhibit this behaviour:
+echo "using System; class T { static int Main() { return 0; } }" > testit.cs
+mcs testit.cs
+while [ $RUN -lt 25 ] ; do
+  mono testit.exe
+  if [ $? == 1 ] ; then
+    let FAIL=FAIL+1
+  fi
+  let RUN=RUN+1
+echo "Runs: $RUN"
+echo "Failed: $FAIL"
+This is an intermittent bug that doesn't happen on every run;
+I traced the code and it appears what is happening is somehow _wapi_timed_thread_destroy is 
+getting called on one of the threads before _wapi_timed_thread_exit.
+** Message: _wapi_timed_thread_destroy(): THREAD: 0x15398e0 MUTEX: 0x2817400
+** Message: _wapi_timed_thread_exit(): THREAD: 0x15398e0 MUTEX: 0x2817400
+As a result because the thread has already been free'd and the mutex_destroyed is throws an 
+assert on that line and doesn't return the correct exit code to the test suite.
+Encapsulating the _wapi_timed_thread_destroy() function with a 
+if(thread->exiting) {} resolves this issue; but I'm too unfamiliar to know if this will have adverse 
+ramifications elsewhere in the threading system.
+Without the if(thread->exiting) modification:
+68 test(s) passed. 111 test(s) failed.
+With the if(thread->existing modification:
+170 test(s) passed. 9 test(s) failed.
+Please note this was tested on 2 different G4 machines; with mono v1.0 and CVS (today) from