Date: Thu, 03 Mar 2005 22:32:41 +0800 From: David Xu <davidxu@freebsd.org> To: Tom McLaughlin <tmclaugh@sdf.lonestar.org> Cc: freebsd-threads@freebsd.org Subject: Re: Mono's XSP crashes on browser connection Message-ID: <42272009.507@freebsd.org> In-Reply-To: <1109835366.777.95.camel@compass.straycat.dhs.org> References: <1109551418.782.30.camel@compass.straycat.dhs.org> <1109742079.777.15.camel@compass.straycat.dhs.org> <422649AF.5090606@freebsd.org> <1109833505.777.80.camel@compass.straycat.dhs.org> <4226B9DC.7040405@freebsd.org> <1109835366.777.95.camel@compass.straycat.dhs.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
>-or-
>$ 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
mono-1.0.6/mono/io-layer/handles.c,
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) {
sleep(1);
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@tiger:/home/davidxu/tests> mono ./testls.exe
shell_path=0x81197c0
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
build.sh 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
loop2
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
stack
but they still works very well. :=(
hope this helps,
David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42272009.507>