[Mono-bugs] [Bug 68134][Maj] Changed - Mono runtime hangs on FreeBSD 4.8

[bugzilla-daemon@bugzilla.ximian.com]

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 cmcclellen@weather.com.

http://bugzilla.ximian.com/show_bug.cgi?id=68134

--- shadow/68134	2004-10-14 15:15:05.000000000 -0400
+++ shadow/68134.tmp.31948	2004-11-16 13:40:04.000000000 -0500
@@ -141,6 +141,32 @@
 and condition variables use the same sleep queue, which causes 
 pthread_cond_broadcast, etc, to go into infinite loops trying to 
 walk them.
 
 We're testing a fix to libc_r now.  I'll change state to notabug, 
 since it doesn't seem to be Mono at all.
+
+------- Additional Comments From cmcclellen@weather.com  2004-11-16 13:40 -------
+As a follow up, we've found some problems in libc_r so have tried 
+FreeBSD 5.x and 6.x (freebsd-current).  What we've found is a few 
+race conditions inside libpthread, and a couple of deadlock 
+situations with signal-handlers.  libgc's suspend handler can cause 
+a deadlock (not libgc's fault).
+
+Other problems include getting signals at the wrong time when 
+waiting on a condition var or a mutex.  These can cause other 
+deadlocks or syncq corruption (depending on when signals are 
+received).  
+
+Testing a patch to freebsd-current right now that makes everything 
+much better.  If it works well, there is a good chance it will get 
+put back into freebsd5.  libc_r will most likely not be able to run 
+mono (so freebsd 4.x will most likely be out of luck unless you use 
+LinuxThreads library).  libc_r needs to be 386 (yes an actual 386) 
+compatible, so there will probably always be a locking bug in it. 
+We'll see.
+
+So currently, freebsd 4.x, 5.x and 6.x will have big problems 
+running mono.  Soon, at least, hopefully 6.x then 5.x will run it 
+fine.
+
+