Mono's XSP crashes on browser connection

David Xu davidxu at
Thu Mar 3 14:32:42 GMT 2005

Tom McLaughlin wrote:

>On Thu, 2005-03-03 at 15:16 +0800, David Xu wrote:
>>Tom McLaughlin wrote:
>>>Disabling garbage collection in Mono prevents the crash but after
>>>executing the external process the C# program does not continue on, it
>>>just sits there.  So that isn't a viable option for regular use.
>>Can you give me example code (executing external program) ?  I don't know C#
>>but want to try.
>Here you go.  The second one yields a slightly different error but it
>more closely matches the code in the program where I first tracked down
>this bug.
>when using gdb with these examples do one of the following:
>$ gdb /usr/local/bin/mono mono.core
>$ gdb /usr/local/bin/mono
>(gdb) run /path/to/foo.exe
>simple example:
>using System.Diagnostics;
>class T
>    static void Main()
>    {
>        Process.Start ("ls");
>    }
>Second example:
>using System.Diagnostics;
>class T
>    static void Main()
>    {
>        ProcessStartInfo pi = new ProcessStartInfo ();
>        pi.FileName = "ls";
>        pi.RedirectStandardOutput = true;
>        pi.UseShellExecute = false;
>        pi.Arguments = "-al";
>        Process.Start (pi);
>    }
>Thanks for taking a look at this.  This bug is making creating ports a
>pain.  The mcs compiler uses this when called with the /pkg flag.  It's
>also keeping XSP and MonoDevelop out of the ports tree.  Those are two
>of the programs I see most requested.
I have digged deeply in mono source code, and found that it is trying
to share pthread_mutex_t via shared memory segments, this is not
supported by current FreeBSD thread library, also the author of mono
is trying to avoid to share mutex between processes according to
whether _POSIX_THREAD_PROCESS_SHARED is defined or not in
source code,  but he failed to respect this macro at many places, so the
macro is rather bogus.

These sampe programs blocked after excuting external program, because WIN32
process handle is not correctly waited in file 
function: _wapi_handle_timedwait_signal_handle(), if you replace
mono_cond_timedwait() call with loop :

                while (!_wapi_handle_get_shared_segment 
(segment)->handles[idx].signalled) {
                        printf("loop \n");

you will find that the process will exit soon,  but it will complain 
another problem, here is
the log on my console:

davidxu at tiger:/home/davidxu/tests> mono ./testls.exe
wait on 1:3233, mutex=0x805a380
a.out               d.core              jointest.c          
nullcond.c          sigwait.c           thr_cancel.c
aqueue.c            d.cpp               ktrace.out          
nullvector          single              thrcreate
aqueue_c_r          deque.cpp           list2               
nullvector.cpp      single.c            thrcreate.c
aqueue_kse          ex14                list2.cpp           
op_pp               spinlock            threadstack
aqueue_linuxthreads ex14.c              list3               
op_pp.cpp           spinlock.c          threadstack.c
aqueue_pthread      examples            list3.cpp           
pp                  stack.cpp           threadstack.core
aqueue_thr          f2c                 malloc              
pp.c                stack.h             two
aqueue_thread       f2c.c               malloc.c            
pp_thr              stlstack            two.c            hello               maxsize             
pp_thread           stlstack.cpp        typeinfo
cancelstress        hello.core          maxsize.cpp         
resume_suspend      strcspn_test        typeinfo.cxx
cancelstress.c      hello.cpp           mono.core           
resume_suspend.c    strcspn_test.c      userdefined_set
cancelstress2       hello.o             mutex_cancel        
rlimit              string              userdefined_set.cpp
cancelstress2.c     iconv               mutex_cancel.c      
rlimit.c            string.cxx          userdefined_set.o
concurr             iconv.c             mutex_sig           
sem                 strpbrk_test        valgrind.core
concurr.c           iostream            mutex_sig.c         
sem.c               strpbrk_test.c      vector
cond                iostream.cxx        mutex_sig2          
set                 t                   vector.cxx
cond.c              join.c              mutex_sig2.c        
set.cpp             test3.cpp           vector2
condwait            joinstress          mutex_test          
sigfork             testls.cs           vector2.cpp
condwait.c          joinstress.c        mutex_test.c        
sigfork.c           testls.exe          vector3
d                   jointest            nullcond            
sigwait             thr_cancel          vector3.cpp
setTRUE: 1 3233
return 2
mono in free(): error: modified (page-) pointer
Abort (core dumped)


I  can write sharable mutex and condition variable for mono, but current
I have no time, because sigwait panic and my kernel umtx can not work with
stupid swapped out kernel stack, I saw other OSes do not swap out kernel 
but they still works very well. :=(

hope this helps,
David Xu

More information about the freebsd-threads mailing list