[Mono-dev] Mono 2.0 and FreeBSD
Hello, [Note to Geoff Norton in CC] I saw a message [0] from you about Mono working on FreeBSD so I put you in CC since you may have some relevant information to provide ;-) [End of note] The BSD# project [1] aims to bring Mono 2.0 on the FreeBSD operating system. While Mono is already available on this platform [2], it is quite outdated: the latests available version is 1.2.5.1. Updating to the latest version is unfortunately not as easy as expected: basically, mono builds without incident, but not all programs are working correctly. Regression tests are causing trouble, so I guess they have to pass before we can try to see what is okay and what is not. In the past few weeks, I tried to track down the mono subversion tree to get to the commit that broke NullReferenceException down: the test mono/tests/exception.exe pass with <=mono-1.2.5.1 but either ABRT or hangs-on with more recent version of mono. I stopped my tests with the version of 2006-10-31 (rev. 67196) from the trunk where the problem is still present. As far I as understand, the development did not took place in trunk or patches where applied for the release since mono-1.2.5 was tagged many month after this date. I am therefore still not able to understand what is happening and I am so trying to get more info at the source. I have put the result of running exception.exe here [3]. The program [3.1] hangs consuming CPU time until it gets killed. I am not sure about the gdb backtrace [3.2]: I followed the instructions about debugging [4] but I have weird results such as: > #3 0x in ?? () > #4 0x in ?? () > #5 0x in ?? () > #6 0x0001 in ?? () > #7 0x in ?? () ... which I don't think is good (too much 0x)... This is on FreeBSD 7.1-PRERELEASE i386 with mono-2.0.1 [3.3]. Any idea for a better backtrace is welcomed. Any hint is welcomed. Any branch of mono to checkout and test too. If required, I can even provide an SSH connection to a FreeBSD box and assistance to a Mono-guru to hack and fix this bug (Okay, I think you understood that I _really_ want this to work on FreeBSD!). I hope that mixing the BSD# team's knowledge of FreeBSD and your knowledge of Mono internals will result in having a working Mono 2.0 on FreeBSD! With kind regards, Romain Tartière, on behalf of the BSD# Project. References: 0. http://lists.ximian.com/pipermail/mono-devel-list/2008-November/029685.html 1. http://code.google.com/p/bsd-sharp/ 2. http://www.freshports.org/lang/mono/ 3. http://mono.sigabrt.org/ 3.1 http://mono.sigabrt.org/exception.cs 3.2 http://mono.sigabrt.org/gdb 3.3 http://mono.sigabrt.org/VERSION 4. http://www.mono-project.com/Debugging -- Romain Tartière <[EMAIL PROTECTED]>http://romain.blogreen.org/ pgp: 8DAB A124 0DA4 7024 F82A E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43) (plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated) pgp6aprmX2xhw.pgp Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.0 and FreeBSD
Hi, It is possible that freebsd changes broke mono, not mono changes. As for the exception failures, running configure with ./configure --with-sigaltstack=no might help. Zoltan 2008/12/8 Romain Tartière <[EMAIL PROTECTED]>: > Hello, > > [Note to Geoff Norton in CC] >I saw a message [0] from you about Mono working on FreeBSD so I put > you in CC since you may have some relevant information to provide ;-) > [End of note] > >The BSD# project [1] aims to bring Mono 2.0 on the FreeBSD operating > system. While Mono is already available on this platform [2], it is > quite outdated: the latests available version is 1.2.5.1. > >Updating to the latest version is unfortunately not as easy as > expected: basically, mono builds without incident, but not all programs > are working correctly. Regression tests are causing trouble, so I guess > they have to pass before we can try to see what is okay and what is not. > >In the past few weeks, I tried to track down the mono subversion > tree to get to the commit that broke NullReferenceException down: the > test mono/tests/exception.exe pass with <=mono-1.2.5.1 but either ABRT > or hangs-on with more recent version of mono. I stopped my tests with the > version of 2006-10-31 (rev. 67196) from the trunk where the problem is > still present. As far I as understand, the development did not took > place in trunk or patches where applied for the release since > mono-1.2.5 was tagged many month after this date. > >I am therefore still not able to understand what is happening and > I am so trying to get more info at the source. I have put the result of > running exception.exe here [3]. The program [3.1] hangs consuming CPU > time until it gets killed. > >I am not sure about the gdb backtrace [3.2]: I followed the > instructions about debugging [4] but I have weird results such as: >> #3 0x in ?? () >> #4 0x in ?? () >> #5 0x in ?? () >> #6 0x0001 in ?? () >> #7 0x in ?? () > ... which I don't think is good (too much 0x)... > >This is on FreeBSD 7.1-PRERELEASE i386 with mono-2.0.1 [3.3]. > >Any idea for a better backtrace is welcomed. Any hint is welcomed. > Any branch of mono to checkout and test too. If required, I can even > provide an SSH connection to a FreeBSD box and assistance to a Mono-guru > to hack and fix this bug (Okay, I think you understood that I _really_ > want this to work on FreeBSD!). > > >I hope that mixing the BSD# team's knowledge of FreeBSD and your > knowledge of Mono internals will result in having a working Mono 2.0 on > FreeBSD! > > > With kind regards, > Romain Tartière, > on behalf of the BSD# Project. > > References: >0. > http://lists.ximian.com/pipermail/mono-devel-list/2008-November/029685.html >1. http://code.google.com/p/bsd-sharp/ >2. http://www.freshports.org/lang/mono/ >3. http://mono.sigabrt.org/ >3.1 http://mono.sigabrt.org/exception.cs >3.2 http://mono.sigabrt.org/gdb >3.3 http://mono.sigabrt.org/VERSION >4. http://www.mono-project.com/Debugging > > -- > Romain Tartière <[EMAIL PROTECTED]>http://romain.blogreen.org/ > pgp: 8DAB A124 0DA4 7024 F82A E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43) > (plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated) > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.0 and FreeBSD
Hello Zoltan! On Mon, Dec 08, 2008 at 03:07:33PM +0100, Zoltan Varga wrote: > It is possible that freebsd changes broke mono, not mono changes. Well, working with mono-1.2.5.1 on my FreeBSD 7.1-PRERELEASE box is okay. Since I can't have mono >=1.2.6 on FreeBSD I am still using it. I I can't however be sure that nothing has been changed in FreeBSD since Mono 1.2.6 was released that could affect mono. > As for the exception failures, running configure with > ./configure --with-sigaltstack=no > might help. Just tried it. Instead of hanging-on, mono aborts. The backtrace in gdb is almost the same, plus ~10 frames that look consistent and are related to signal handling: gdb ../mini/mono mono.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Core was generated by `mono'. Program terminated with signal 6, Aborted. Reading symbols from /usr/local/lib/libgthread-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgthread-2.0.so.0 Reading symbols from /usr/local/lib/libglib-2.0.so.0...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.0 Reading symbols from /usr/local/lib/libicui18n.so.38...done. Loaded symbols for /usr/local/lib/libicui18n.so.38 Reading symbols from /usr/local/lib/libintl.so.8...done. Loaded symbols for /usr/local/lib/libintl.so.8 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/local/lib/libpcre.so.0...done. Loaded symbols for /usr/local/lib/libpcre.so.0 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/libicuuc.so.38...done. Loaded symbols for /usr/local/lib/libicuuc.so.38 Reading symbols from /usr/local/lib/libicudata.so.38...done. Loaded symbols for /usr/local/lib/libicudata.so.38 Reading symbols from /usr/lib/libstdc++.so.6...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x286f5463 in thr_kill () at thr_kill.S:2 warning: Source file is more recent than executable. 2 RSYSCALL(thr_kill) [New Thread 0x29576c00 (LWP 100399)] [New Thread 0x29576100 (LWP 100101)] [New Thread 0x29501100 (LWP 100493)] (gdb) bt #0 0x286f5463 in thr_kill () at thr_kill.S:2 #1 0x286aad99 in _thr_send_sig (thread=0x29501100, sig=6) at /usr/src/lib/libthr/thread/thr_kern.c:92 #2 0x286a8c9b in _raise (sig=6) at /usr/src/lib/libthr/thread/thr_sig.c:178 #3 0x28784104 in abort () at /usr/src/lib/libc/stdlib/abort.c:65 #4 0x0806d52f in mono_handle_native_sigsegv (signal=11, ctx=0xbfbfdde4) at mini-exceptions.c:1365 #5 0x0820884a in sigsegv_signal_handler (_dummy=11) at mini.c:13441 #6 #7 0x08071f91 in mono_arch_is_int_overflow (sigctx=0xbfbfe194, info=0x0) at mini-x86.c:688 #8 0x08208736 in sigfpe_signal_handler (_dummy=8) at mini.c:13344 #9 #10 0x299a22db in ?? () #11 0xbfbfe804 in ?? () #12 0xbfbfe4f4 in ?? () #13 0x in ?? () #14 0x in ?? () #15 0x in ?? () #16 0x0001 in ?? () #17 0x in ?? () #18 0x2951903c in ?? () #19 0xbfbfe4d8 in ?? () #20 0xbfbfe4f4 in ?? () #21 0xbfbfe804 in ?? () #22 0x000a in ?? () #23 0xbfbfe4f4 in ?? () #24 0x299a2261 in ?? () #25 0x in ?? () #26 0x in ?? () #27 0xbfbfe518 in ?? () #28 0x299a21c3 in ?? () #29 0x080d8efe in mono_custom_attrs_from_index (image=0x0, idx=0) at reflection.c:7730 Previous frame inner to this frame (corrupt stack?) (gdb) The line « warning: Source file is more recent than executable. » makes me feel uncomfortable however. Regards, Romain -- Romain Tartière <[EMAIL PROTECTED]>http://romain.blogreen.org/ pgp: 8DAB A124 0DA4 7024 F82A E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43) (plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated) pgprGaIcJFAf1.pgp Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.0 and FreeBSD
Its also worth noting that mono building itself is no small feat. If there are specific programs/tests failing with mono (without some set of unknown freebsd patches applied), please file bugs for each of the issues. -g On Mon, 2008-12-08 at 15:07 +0100, Zoltan Varga wrote: > Hi, > > It is possible that freebsd changes broke mono, not mono changes. As for the > exception failures, running configure with > ./configure --with-sigaltstack=no > might help. > >Zoltan > > 2008/12/8 Romain Tartière <[EMAIL PROTECTED]>: > > Hello, > > > > [Note to Geoff Norton in CC] > >I saw a message [0] from you about Mono working on FreeBSD so I put > > you in CC since you may have some relevant information to provide ;-) > > [End of note] > > > >The BSD# project [1] aims to bring Mono 2.0 on the FreeBSD operating > > system. While Mono is already available on this platform [2], it is > > quite outdated: the latests available version is 1.2.5.1. > > > >Updating to the latest version is unfortunately not as easy as > > expected: basically, mono builds without incident, but not all programs > > are working correctly. Regression tests are causing trouble, so I guess > > they have to pass before we can try to see what is okay and what is not. > > > >In the past few weeks, I tried to track down the mono subversion > > tree to get to the commit that broke NullReferenceException down: the > > test mono/tests/exception.exe pass with <=mono-1.2.5.1 but either ABRT > > or hangs-on with more recent version of mono. I stopped my tests with the > > version of 2006-10-31 (rev. 67196) from the trunk where the problem is > > still present. As far I as understand, the development did not took > > place in trunk or patches where applied for the release since > > mono-1.2.5 was tagged many month after this date. > > > >I am therefore still not able to understand what is happening and > > I am so trying to get more info at the source. I have put the result of > > running exception.exe here [3]. The program [3.1] hangs consuming CPU > > time until it gets killed. > > > >I am not sure about the gdb backtrace [3.2]: I followed the > > instructions about debugging [4] but I have weird results such as: > >> #3 0x in ?? () > >> #4 0x in ?? () > >> #5 0x in ?? () > >> #6 0x0001 in ?? () > >> #7 0x in ?? () > > ... which I don't think is good (too much 0x)... > > > >This is on FreeBSD 7.1-PRERELEASE i386 with mono-2.0.1 [3.3]. > > > >Any idea for a better backtrace is welcomed. Any hint is welcomed. > > Any branch of mono to checkout and test too. If required, I can even > > provide an SSH connection to a FreeBSD box and assistance to a Mono-guru > > to hack and fix this bug (Okay, I think you understood that I _really_ > > want this to work on FreeBSD!). > > > > > >I hope that mixing the BSD# team's knowledge of FreeBSD and your > > knowledge of Mono internals will result in having a working Mono 2.0 on > > FreeBSD! > > > > > > With kind regards, > > Romain Tartière, > > on behalf of the BSD# Project. > > > > References: > >0. > > http://lists.ximian.com/pipermail/mono-devel-list/2008-November/029685.html > >1. http://code.google.com/p/bsd-sharp/ > >2. http://www.freshports.org/lang/mono/ > >3. http://mono.sigabrt.org/ > >3.1 http://mono.sigabrt.org/exception.cs > >3.2 http://mono.sigabrt.org/gdb > >3.3 http://mono.sigabrt.org/VERSION > >4. http://www.mono-project.com/Debugging > > > > -- > > Romain Tartière <[EMAIL PROTECTED]>http://romain.blogreen.org/ > > pgp: 8DAB A124 0DA4 7024 F82A E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43) > > (plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated) > > > > ___ > > Mono-devel-list mailing list > > Mono-devel-list@lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.0 and FreeBSD
On Mon, 2008-12-08 at 16:14 +0100, Romain Tartière wrote: > > The line « warning: Source file is more recent than executable. » makes > me feel uncomfortable however. > This is more than uncomfortable, it means we cannot trust any of your stack traces. -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.0 and FreeBSD
Hi Geoff On Mon, Dec 08, 2008 at 11:43:19AM -0500, Geoff Norton wrote: > On Mon, 2008-12-08 at 16:14 +0100, Romain Tartière wrote: > > The line « warning: Source file is more recent than executable. » makes > > me feel uncomfortable however. > This is more than uncomfortable, it means we cannot trust any of your > stack traces. Yup! I wrote `uncomfortable' since basically, this is what I get when the tarball is extracted to en empty directory, configure is run ... | $ PTHREAD_LIBS="-pthread" \ | ./configure --program-transform-name='' \ | --with-moonlinght=no \ | --with-preview=yes \ | --with-sigaltstack=no \ | --prefix=/usr/local \ | --mandir=/usr/local/man \ | --infodir=/usr/local/info/ \ | --build=i386-portbld-freebsd7.1 (Full configuration log available [1]) ... project is built ... | $ gmake EXTERNAL_MCS=false ... and I run tests ... | $ cd mono/tests && gmake test | ... | Testing bitconverter.exe... pass. | Testing exception.exe... Abort trap (core dumped) | failed 34304 (134) signal (0). I only tweaked mono/tests/Makefile so that is breaks as soon as a test fails. | $ gdb ../mini/mono mono.core | ... | #0 0x286f5463 in thr_kill () at thr_kill.S:2 | | warning: Source file is more recent than executable. | | 2 RSYSCALL(thr_kill) | [New Thread 0x29559f00 (LWP 100145)] | [New Thread 0x29559100 (LWP 100101)] | [New Thread 0x29501100 (LWP 100393)] | (gdb) So, no source file is changed after the code has been built... I guess something weird is happening... Regards, Romain References: 1. http://mono.sigabrt.org/config.log -- Romain Tartière <[EMAIL PROTECTED]>http://romain.blogreen.org/ pgp: 8DAB A124 0DA4 7024 F82A E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43) (plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated) pgpAaOPQMGqwQ.pgp Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.0 and FreeBSD
On Mon, Dec 08, 2008 at 04:14:45PM +0100, Romain Tartière wrote:
> > As for the exception failures, running configure with
> > ./configure --with-sigaltstack=no
> > might help.
> Just tried it. Instead of hanging-on, mono aborts. The backtrace in gdb
> is almost the same, plus ~10 frames that look consistent and are related
> to signal handling
Wow! I have just discovered that a patch in the FreeBSD port remove the
explicit activation of sigaltstack [1]. I removed all patches we provide
and only kept path fixes (e.g. /usr/bin/env {bash,perl} instead of
/bin/{bash,perl}).
The result is exactly the same (with a backtrace for all threads). You
can consider this "vanilla mono 2.0.1":
| $ gdb ../mini/mono
| GNU gdb 6.1.1 [FreeBSD]
| Copyright 2004 Free Software Foundation, Inc.
| GDB is free software, covered by the GNU General Public License, and you are
| welcome to change it and/or distribute copies of it under certain conditions.
| Type "show copying" to see the conditions.
| There is absolutely no warranty for GDB. Type "show warranty" for details.
| This GDB was configured as "i386-marcel-freebsd"...
| (gdb) r exception.exe
| Starting program:
/usr/home/romain/Projects/BSD-sharp-latest/lang/mono/work/mono-2.0.1/mono/mini/mono
exception.exe
| [New LWP 100408]
| [New Thread 0x29501100 (LWP 100408)]
| [New Thread 0x29564100 (LWP 100388)]
| [New Thread 0x29564c00 (LWP 100443)]
|
| Program received signal SIGFPE, Arithmetic exception.
| [Switching to Thread 0x29501100 (LWP 100408)]
| 0x294dc2d3 in ?? ()
| (gdb) thread apply all bt
|
| Thread 4 (Thread 0x29564c00 (LWP 100443)):
| #0 0x286ad3a3 in _umtx_op_err () at
/usr/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36
| #1 0x286ad141 in _thr_ucond_wait (cv=0x2956eae0, m=0x2956eac0, timeout=0x0,
check_unparking=1)
| at /usr/src/lib/libthr/thread/thr_umtx.c:129
| #2 0x286abb6d in cond_wait_common (cond=Variable "cond" is not available.
| ) at /usr/src/lib/libthr/thread/thr_cond.c:204
| #3 0x08191281 in timedwait_signal_poll_cond (cond=0x295740f0,
mutex=0x295740ec, timeout=0x0, alertable=0)
| at handles.c:1490
| #4 0x081915c6 in _wapi_handle_timedwait_signal_handle (handle=0x5804,
timeout=0x0, alertable=0)
| at handles.c:1570
| #5 0x081913cc in _wapi_handle_wait_signal_handle (handle=0x5804,
alertable=0) at handles.c:1530
| #6 0x081afbf8 in WaitForSingleObjectEx (handle=0x5804, timeout=4294967295,
alertable=0) at wait.c:205
| #7 0x0810182f in finalizer_thread (unused=0x0) at gc.c:908
| #8 0x08122d52 in start_wrapper (data=0x2956f960) at threads.c:621
| #9 0x081a9d8a in thread_start_routine (args=0x295741d4) at threads.c:279
| #10 0x081cd98e in GC_start_routine (arg=0x832bec0) at pthread_support.c:1382
| #11 0x286a5865 in thread_start (curthread=0x29564c00) at
/usr/src/lib/libthr/thread/thr_create.c:256
| #12 0x in ?? ()
| Current language: auto; currently asm
|
| Thread 3 (Thread 0x29564100 (LWP 100388)):
| #0 0x28769f53 in nanosleep () at nanosleep.S:2
| #1 0x286a47e2 in __nanosleep (time_to_sleep=0xbf9fef8c, time_remaining=0x0)
| at /usr/src/lib/libthr/thread/thr_syscalls.c:306
| #2 0x0818bcf5 in collection_thread (unused=0x0) at collection.c:34
| #3 0x286a5865 in thread_start (curthread=0x29564100) at
/usr/src/lib/libthr/thread/thr_create.c:256
| #4 0x in ?? ()
|
| Thread 2 (Thread 0x29501100 (LWP 100408)):
| #0 0x294dc2d3 in ?? ()
| #1 0xbfbfe774 in ?? ()
| #2 0xbfbfe474 in ?? ()
| #3 0x in ?? ()
| #4 0x in ?? ()
| #5 0x in ?? ()
| #6 0x0001 in ?? ()
| #7 0x in ?? ()
| #8 0x2951903c in ?? ()
| #9 0xbfbfe458 in ?? ()
| #10 0xbfbfe474 in ?? ()
| #11 0xbfbfe774 in ?? ()
| ---Type to continue, or q to quit---
| #12 0x000a in ?? ()
| #13 0xbfbfe474 in ?? ()
| #14 0x294dc259 in ?? ()
| #15 0x in ?? ()
| #16 0x in ?? ()
| #17 0xbfbfe498 in ?? ()
| #18 0x294dc1b7 in ?? ()
| #19 0x080d935e in mono_custom_attrs_from_index (image=0x0, idx=0) at
reflection.c:7730
| Previous frame inner to this frame (corrupt stack?)
| (gdb)
With regards,
Romain
References:
1.
http://code.google.com/p/bsd-sharp/source/browse/trunk/lang/mono/files/patch-configure
--
Romain Tartière <[EMAIL PROTECTED]>http://romain.blogreen.org/
pgp: 8DAB A124 0DA4 7024 F82A E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)
pgpfyM1G9wqBZ.pgp
Description: PGP signature
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.0 and FreeBSD
Please file a bug for this issue in bugzilla and assign it to me.
-g
On Tue, 2008-12-09 at 12:57 +0100, Romain Tartière wrote:
> On Mon, Dec 08, 2008 at 04:14:45PM +0100, Romain Tartière wrote:
> > > As for the exception failures, running configure with
> > > ./configure --with-sigaltstack=no
> > > might help.
> > Just tried it. Instead of hanging-on, mono aborts. The backtrace in gdb
> > is almost the same, plus ~10 frames that look consistent and are related
> > to signal handling
>
> Wow! I have just discovered that a patch in the FreeBSD port remove the
> explicit activation of sigaltstack [1]. I removed all patches we provide
> and only kept path fixes (e.g. /usr/bin/env {bash,perl} instead of
> /bin/{bash,perl}).
>
> The result is exactly the same (with a backtrace for all threads). You
> can consider this "vanilla mono 2.0.1":
>
> | $ gdb ../mini/mono
> | GNU gdb 6.1.1 [FreeBSD]
> | Copyright 2004 Free Software Foundation, Inc.
> | GDB is free software, covered by the GNU General Public License, and you are
> | welcome to change it and/or distribute copies of it under certain
> conditions.
> | Type "show copying" to see the conditions.
> | There is absolutely no warranty for GDB. Type "show warranty" for details.
> | This GDB was configured as "i386-marcel-freebsd"...
> | (gdb) r exception.exe
> | Starting program:
> /usr/home/romain/Projects/BSD-sharp-latest/lang/mono/work/mono-2.0.1/mono/mini/mono
> exception.exe
> | [New LWP 100408]
> | [New Thread 0x29501100 (LWP 100408)]
> | [New Thread 0x29564100 (LWP 100388)]
> | [New Thread 0x29564c00 (LWP 100443)]
> |
> | Program received signal SIGFPE, Arithmetic exception.
> | [Switching to Thread 0x29501100 (LWP 100408)]
> | 0x294dc2d3 in ?? ()
> | (gdb) thread apply all bt
> |
> | Thread 4 (Thread 0x29564c00 (LWP 100443)):
> | #0 0x286ad3a3 in _umtx_op_err () at
> /usr/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36
> | #1 0x286ad141 in _thr_ucond_wait (cv=0x2956eae0, m=0x2956eac0,
> timeout=0x0, check_unparking=1)
> | at /usr/src/lib/libthr/thread/thr_umtx.c:129
> | #2 0x286abb6d in cond_wait_common (cond=Variable "cond" is not available.
> | ) at /usr/src/lib/libthr/thread/thr_cond.c:204
> | #3 0x08191281 in timedwait_signal_poll_cond (cond=0x295740f0,
> mutex=0x295740ec, timeout=0x0, alertable=0)
> | at handles.c:1490
> | #4 0x081915c6 in _wapi_handle_timedwait_signal_handle (handle=0x5804,
> timeout=0x0, alertable=0)
> | at handles.c:1570
> | #5 0x081913cc in _wapi_handle_wait_signal_handle (handle=0x5804,
> alertable=0) at handles.c:1530
> | #6 0x081afbf8 in WaitForSingleObjectEx (handle=0x5804, timeout=4294967295,
> alertable=0) at wait.c:205
> | #7 0x0810182f in finalizer_thread (unused=0x0) at gc.c:908
> | #8 0x08122d52 in start_wrapper (data=0x2956f960) at threads.c:621
> | #9 0x081a9d8a in thread_start_routine (args=0x295741d4) at threads.c:279
> | #10 0x081cd98e in GC_start_routine (arg=0x832bec0) at pthread_support.c:1382
> | #11 0x286a5865 in thread_start (curthread=0x29564c00) at
> /usr/src/lib/libthr/thread/thr_create.c:256
> | #12 0x in ?? ()
> | Current language: auto; currently asm
> |
> | Thread 3 (Thread 0x29564100 (LWP 100388)):
> | #0 0x28769f53 in nanosleep () at nanosleep.S:2
> | #1 0x286a47e2 in __nanosleep (time_to_sleep=0xbf9fef8c, time_remaining=0x0)
> | at /usr/src/lib/libthr/thread/thr_syscalls.c:306
> | #2 0x0818bcf5 in collection_thread (unused=0x0) at collection.c:34
> | #3 0x286a5865 in thread_start (curthread=0x29564100) at
> /usr/src/lib/libthr/thread/thr_create.c:256
> | #4 0x in ?? ()
> |
> | Thread 2 (Thread 0x29501100 (LWP 100408)):
> | #0 0x294dc2d3 in ?? ()
> | #1 0xbfbfe774 in ?? ()
> | #2 0xbfbfe474 in ?? ()
> | #3 0x in ?? ()
> | #4 0x in ?? ()
> | #5 0x in ?? ()
> | #6 0x0001 in ?? ()
> | #7 0x in ?? ()
> | #8 0x2951903c in ?? ()
> | #9 0xbfbfe458 in ?? ()
> | #10 0xbfbfe474 in ?? ()
> | #11 0xbfbfe774 in ?? ()
> | ---Type to continue, or q to quit---
> | #12 0x000a in ?? ()
> | #13 0xbfbfe474 in ?? ()
> | #14 0x294dc259 in ?? ()
> | #15 0x in ?? ()
> | #16 0x in ?? ()
> | #17 0xbfbfe498 in ?? ()
> | #18 0x294dc1b7 in ?? ()
> | #19 0x080d935e in mono_custom_attrs_from_index (image=0x0, idx=0) at
> reflection.c:7730
> | Previous frame inner to this frame (corrupt stack?)
> | (gdb)
>
> With regards,
> Romain
>
> References:
> 1.
> http://code.google.com/p/bsd-sharp/source/browse/trunk/lang/mono/files/patch-configure
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.0 and FreeBSD
Actually scratch that, the SIGFPE is expected there, it gets translated
into an exception by our runtime. Have you tried compiling with
sigaltstack off as asked by zoltan? I updated my 7.0 VM to mono trunk,
and fail in exceptions.cs with the altstack code on. (I havn't tested
with it off yet)
-g
On Tue, 2008-12-09 at 11:30 -0500, Geoff Norton wrote:
> Please file a bug for this issue in bugzilla and assign it to me.
>
> -g
>
> On Tue, 2008-12-09 at 12:57 +0100, Romain Tartière wrote:
> > On Mon, Dec 08, 2008 at 04:14:45PM +0100, Romain Tartière wrote:
> > > > As for the exception failures, running configure with
> > > > ./configure --with-sigaltstack=no
> > > > might help.
> > > Just tried it. Instead of hanging-on, mono aborts. The backtrace in gdb
> > > is almost the same, plus ~10 frames that look consistent and are related
> > > to signal handling
> >
> > Wow! I have just discovered that a patch in the FreeBSD port remove the
> > explicit activation of sigaltstack [1]. I removed all patches we provide
> > and only kept path fixes (e.g. /usr/bin/env {bash,perl} instead of
> > /bin/{bash,perl}).
> >
> > The result is exactly the same (with a backtrace for all threads). You
> > can consider this "vanilla mono 2.0.1":
> >
> > | $ gdb ../mini/mono
> > | GNU gdb 6.1.1 [FreeBSD]
> > | Copyright 2004 Free Software Foundation, Inc.
> > | GDB is free software, covered by the GNU General Public License, and you
> > are
> > | welcome to change it and/or distribute copies of it under certain
> > conditions.
> > | Type "show copying" to see the conditions.
> > | There is absolutely no warranty for GDB. Type "show warranty" for
> > details.
> > | This GDB was configured as "i386-marcel-freebsd"...
> > | (gdb) r exception.exe
> > | Starting program:
> > /usr/home/romain/Projects/BSD-sharp-latest/lang/mono/work/mono-2.0.1/mono/mini/mono
> > exception.exe
> > | [New LWP 100408]
> > | [New Thread 0x29501100 (LWP 100408)]
> > | [New Thread 0x29564100 (LWP 100388)]
> > | [New Thread 0x29564c00 (LWP 100443)]
> > |
> > | Program received signal SIGFPE, Arithmetic exception.
> > | [Switching to Thread 0x29501100 (LWP 100408)]
> > | 0x294dc2d3 in ?? ()
> > | (gdb) thread apply all bt
> > |
> > | Thread 4 (Thread 0x29564c00 (LWP 100443)):
> > | #0 0x286ad3a3 in _umtx_op_err () at
> > /usr/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36
> > | #1 0x286ad141 in _thr_ucond_wait (cv=0x2956eae0, m=0x2956eac0,
> > timeout=0x0, check_unparking=1)
> > | at /usr/src/lib/libthr/thread/thr_umtx.c:129
> > | #2 0x286abb6d in cond_wait_common (cond=Variable "cond" is not available.
> > | ) at /usr/src/lib/libthr/thread/thr_cond.c:204
> > | #3 0x08191281 in timedwait_signal_poll_cond (cond=0x295740f0,
> > mutex=0x295740ec, timeout=0x0, alertable=0)
> > | at handles.c:1490
> > | #4 0x081915c6 in _wapi_handle_timedwait_signal_handle (handle=0x5804,
> > timeout=0x0, alertable=0)
> > | at handles.c:1570
> > | #5 0x081913cc in _wapi_handle_wait_signal_handle (handle=0x5804,
> > alertable=0) at handles.c:1530
> > | #6 0x081afbf8 in WaitForSingleObjectEx (handle=0x5804,
> > timeout=4294967295, alertable=0) at wait.c:205
> > | #7 0x0810182f in finalizer_thread (unused=0x0) at gc.c:908
> > | #8 0x08122d52 in start_wrapper (data=0x2956f960) at threads.c:621
> > | #9 0x081a9d8a in thread_start_routine (args=0x295741d4) at threads.c:279
> > | #10 0x081cd98e in GC_start_routine (arg=0x832bec0) at
> > pthread_support.c:1382
> > | #11 0x286a5865 in thread_start (curthread=0x29564c00) at
> > /usr/src/lib/libthr/thread/thr_create.c:256
> > | #12 0x in ?? ()
> > | Current language: auto; currently asm
> > |
> > | Thread 3 (Thread 0x29564100 (LWP 100388)):
> > | #0 0x28769f53 in nanosleep () at nanosleep.S:2
> > | #1 0x286a47e2 in __nanosleep (time_to_sleep=0xbf9fef8c,
> > time_remaining=0x0)
> > | at /usr/src/lib/libthr/thread/thr_syscalls.c:306
> > | #2 0x0818bcf5 in collection_thread (unused=0x0) at collection.c:34
> > | #3 0x286a5865 in thread_start (curthread=0x29564100) at
> > /usr/src/lib/libthr/thread/thr_create.c:256
> > | #4 0x in ?? ()
> > |
> > | Thread 2 (Thread 0x29501100 (LWP 100408)):
> > | #0 0x294dc2d3 in ?? ()
> > | #1 0xbfbfe774 in ?? ()
> > | #2 0xbfbfe474 in ?? ()
> > | #3 0x in ?? ()
> > | #4 0x in ?? ()
> > | #5 0x in ?? ()
> > | #6 0x0001 in ?? ()
> > | #7 0x in ?? ()
> > | #8 0x2951903c in ?? ()
> > | #9 0xbfbfe458 in ?? ()
> > | #10 0xbfbfe474 in ?? ()
> > | #11 0xbfbfe774 in ?? ()
> > | ---Type to continue, or q to quit---
> > | #12 0x000a in ?? ()
> > | #13 0xbfbfe474 in ?? ()
> > | #14 0x294dc259 in ?? ()
> > | #15 0x in ?? ()
> > | #16 0x in ?? ()
> > | #17 0xbfbfe498 in ?? ()
> > | #18 0x294dc1b7 in ?? ()
> > | #19 0x080d935e in mono_custom_attrs_from_index (image=0x0, idx=0) at
> > reflection.c:7730
> > | Previous frame inner to this frame (corrupt stack?)
> > | (gdb)
> >
> > With r
Re: [Mono-dev] Mono 2.0 and FreeBSD
El mar, 09-12-2008 a las 11:40 -0500, Geoff Norton escribió: > Actually scratch that, the SIGFPE is expected there, it gets translated > into an exception by our runtime. Have you tried compiling with > sigaltstack off as asked by zoltan? I updated my 7.0 VM to mono trunk, > and fail in exceptions.cs with the altstack code on. (I havn't tested > with it off yet) > > -g Would it help if i setup a script that pulls mono from trunk every night, and reports the compilation and test results in a web? Is there such thing already? sorry if there is one.. Thanks! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.0 and FreeBSD
On Wed, Dec 10, 2008 at 02:34:38PM +0100, Romain Tartière wrote: > I don't think it is related to my kernel configuration but I'll give the > GENERIC kernel a try since I have no better idea for now. > case somebody sees something obvious Okay, I have updated my source tree and rebuilt world and the GENERIC kernel. I am now running: | $ uname -a | FreeBSD marvin.blogreen.org 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Wed Dec 10 15:20:29 CET 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 I cleaned the mono directory, removed my /etc/make.conf file and rebuilt mono once more. The result is exactly the same: | 301 test(s) passed. 11 test(s) did not pass. | | Failed tests: | | exception.exe | exception2.exe | exception3.exe | exception4.exe | exception5.exe | remoting2.exe | remoting3.exe | generics-sharing.2.exe | generic-null-call.2.exe | thunks.exe | bug-78549.exe | gmake: *** [testjit] Error 1 | *** Error code 2 always with the message ... | Program received signal SIGFPE, Arithmetic exception. ... in gdb. Phillip, did you tweaked something else? Do you run i386? Thanks! Romain -- Romain Tartière <[EMAIL PROTECTED]>http://romain.blogreen.org/ pgp: 8DAB A124 0DA4 7024 F82A E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43) (plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated) pgpQvoyDyQoey.pgp Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.0 and FreeBSD
On Wed, Dec 10, 2008 at 08:12:42PM -0300, Phillip N. wrote: > > El mié, 10-12-2008 a las 16:08 +0100, Romain Tartière escribió: > > always with the message ... > > | Program received signal SIGFPE, Arithmetic exception. > > ... in gdb. > > > > Phillip, did you tweaked something else? Do you run i386? > > > Hi Romain (and all...) > > The effect of the modification of mini.c vary between amd64 and i386. > [ #undef MONO_ARCH_SIGSEGV_ON_ALTSTACK ] > > On i386 when enabling --with-signaltstack=no thing does not work as on > amd64. Not work, meaning the modification above does not fix the test > failures. > So currently im setting it to yes on i386 on the port's Makefile (please > test it!) make tests | ===> Running mono regression tests | Testing array-init.exe... pass. | Testing arraylist.exe... pass. | [...] | Testing delegate.exe... pass. | Testing bitconverter.exe... pass. | Testing exception.exe... pass. | Testing exception2.exe... pass. | Testing exception3.exe... pass. | Testing exception4.exe... pass. | Testing exception5.exe... pass. | Testing exception6.exe... pass. | [...] | Testing thunks.exe... failed 2048 (8) signal (0). | [...] | Testing generic-valuetype-newobj.2.exe... pass. | 311 test(s) passed. 1 test(s) did not pass. | | Failed tests: | | thunks.exe | gmake: *** [testjit] Erreur 1 | *** Error code 2 It's not 100% okay but... __ __ _ \ \ / /_ _ _ _| | \ V / _` | | | | | | | (_| | |_| |_| |_|\__,_|\__, (_) |___/ This unbreaks a lot of things! > often on i386 i see the following message: > "Thread 8363c00 has exited with leftover thread-specific data after 4 > destructor iterations" I can confirm this. Always though it was some verboise message directly caused my compiling with debugging stuff, so I never took the time to figure out if it was a FreeBSD specific problem. THANKS ! -- Romain Tartière <[EMAIL PROTECTED]>http://romain.blogreen.org/ pgp: 8DAB A124 0DA4 7024 F82A E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43) (plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated) pgp6ukWe9dQSN.pgp Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.0 and FreeBSD
Hi, Romain Tartière wrote: > On Wed, Dec 10, 2008 at 08:12:42PM -0300, Phillip N. wrote: >> El mié, 10-12-2008 a las 16:08 +0100, Romain Tartière escribió: >>> always with the message ... >>> | Program received signal SIGFPE, Arithmetic exception. >>> ... in gdb. >>> >>> Phillip, did you tweaked something else? Do you run i386? >>> >> Hi Romain (and all...) >> >> The effect of the modification of mini.c vary between amd64 and i386. >> [ #undef MONO_ARCH_SIGSEGV_ON_ALTSTACK ] >> >> On i386 when enabling --with-signaltstack=no thing does not work as on >> amd64. Not work, meaning the modification above does not fix the test >> failures. >> So currently im setting it to yes on i386 on the port's Makefile (please >> test it!) > > make tests > | [...] > | Testing thunks.exe... failed 2048 (8) signal (0). > | [...] In mono/tests/libtest.c, search for the only line containing __APPLE__ and change it to match FreeBSD as well. Then rerun the test. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.0 and FreeBSD
On Thu, Dec 11, 2008 at 01:09:57PM +0100, Robert Jordan wrote: > > make tests > > | [...] > > | Testing thunks.exe... failed 2048 (8) signal (0). > > | [...] > > In mono/tests/libtest.c, search for the only line containing > __APPLE__ and change it to match FreeBSD as well. > Then rerun the test. 312 test(s) passed. 0 test(s) did not pass. Great! make exits with 0 now! Patch available here: http://bsd-sharp.googlecode.com/svn/trunk/lang/mono/files/patch-mono_tests_libtest.c Before I fill-in / complete a bug report, can you please Phillip tell me more about the problem you have with the thunks.exe test: in a private mail you told me it failed too on your machine. As far as I see, the chage I made will not affect you since we have a "#if defined(__i386__)" and you are running amd64, don't you? Thank's! Romain -- Romain Tartière http://romain.blogreen.org/ pgp: 8DAB A124 0DA4 7024 F82A E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43) (plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated) pgpyWcX8nLjiC.pgp Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.0 and FreeBSD
Hi all,
El vie, 12-12-2008 a las 17:42 +0100, Romain Tartière escribió:
> On Thu, Dec 11, 2008 at 01:09:57PM +0100, Robert Jordan wrote:
> > > make tests
> > > | [...]
> > > | Testing thunks.exe... failed 2048 (8) signal (0).
> > > | [...]
> >
> > In mono/tests/libtest.c, search for the only line containing
> > __APPLE__ and change it to match FreeBSD as well.
> > Then rerun the test.
>
> 312 test(s) passed. 0 test(s) did not pass.
>
> Great! make exits with 0 now!
>
> Patch available here:
> http://bsd-sharp.googlecode.com/svn/trunk/lang/mono/files/patch-mono_tests_libtest.c
>
> Before I fill-in / complete a bug report, can you please Phillip tell me
> more about the problem you have with the thunks.exe test: in a private
> mail you told me it failed too on your machine. As far as I see, the
> chage I made will not affect you since we have a "#if defined(__i386__)"
> and you are running amd64, don't you?
It works on AMD64 too :)
Currently the only failure is pinvoke2 (on amd64 only, i386 works)
Can anyone give us a hand with this?
This is whats failing:
public static int test_0_marshal_stringbuilder_array () {
StringBuilder sb1 = new StringBuilder ("ABC");
StringBuilder sb2 = new StringBuilder ("DEF");
int res = mono_test_marshal_stringbuilder_array (new
StringBuilder [] { sb1, sb2 });
if (res != 0)
return res;
if (sb1.ToString () != "DEF")
return 5;
if (sb2.ToString () != "ABC")
return 6;
return 0;
}
libtest.c:
LIBTEST_API int STDCALL
mono_test_marshal_stringbuilder_array (char **array)
{
if (strcmp (array [0], "ABC"))
return 1;
if (strcmp (array [1], "DEF"))
return 2;
strcpy (array [0], "DEF");
strcpy (array [1], "ABC");
return 0;
}
Its returning 1.
If i could provide more info please tell!
Thanks in advance!!
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.0 and FreeBSD
El sáb, 13-12-2008 a las 15:14 -0300, Phillip N. escribió: > Currently the only failure is pinvoke2 (on amd64 only, i386 works) Please see https://bugzilla.novell.com/show_bug.cgi?id=458931 Thanks! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.0 and FreeBSD
Dear Romain,
>>> As for the exception failures, running configure with
>>> ./configure --with-sigaltstack=no
>>> might help.
>> Just tried it. Instead of hanging-on, mono aborts. The backtrace in gdb
>> is almost the same, plus ~10 frames that look consistent and are related
>> to signal handling
>
> Wow! I have just discovered that a patch in the FreeBSD port remove the
> explicit activation of sigaltstack [1]. I removed all patches we provide
> and only kept path fixes (e.g. /usr/bin/env {bash,perl} instead of
> /bin/{bash,perl}).
>
> The result is exactly the same (with a backtrace for all threads). You
> can consider this "vanilla mono 2.0.1":
The problem is indeed related to ALTSTACK. I have posted a bug about SIGSEGV,
with the following workaround:
Add in mono.c
#undef MONO_ARCH_SIGSEGV_ON_ALTSTACK
https://bugzilla.novell.com/show_bug.cgi?id=448131
> | $ gdb ../mini/mono
> | GNU gdb 6.1.1 [FreeBSD]
> | Copyright 2004 Free Software Foundation, Inc.
> | GDB is free software, covered by the GNU General Public License, and you are
> | welcome to change it and/or distribute copies of it under certain
> conditions.
> | Type "show copying" to see the conditions.
> | There is absolutely no warranty for GDB. Type "show warranty" for details.
> | This GDB was configured as "i386-marcel-freebsd"...
> | (gdb) r exception.exe
> | Starting program:
> /usr/home/romain/Projects/BSD-sharp-latest/lang/mono/work/mono-2.0.1/mono/mini/mono
> exception.exe
> | [New LWP 100408]
> | [New Thread 0x29501100 (LWP 100408)]
> | [New Thread 0x29564100 (LWP 100388)]
> | [New Thread 0x29564c00 (LWP 100443)]
> |
> | Program received signal SIGFPE, Arithmetic exception.
> | [Switching to Thread 0x29501100 (LWP 100408)]
> | 0x294dc2d3 in ?? ()
> | (gdb) thread apply all bt
> |
> | Thread 4 (Thread 0x29564c00 (LWP 100443)):
> | #0 0x286ad3a3 in _umtx_op_err () at
> /usr/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36
> | #1 0x286ad141 in _thr_ucond_wait (cv=0x2956eae0, m=0x2956eac0,
> timeout=0x0, check_unparking=1)
> | at /usr/src/lib/libthr/thread/thr_umtx.c:129
> | #2 0x286abb6d in cond_wait_common (cond=Variable "cond" is not available.
> | ) at /usr/src/lib/libthr/thread/thr_cond.c:204
> | #3 0x08191281 in timedwait_signal_poll_cond (cond=0x295740f0,
> mutex=0x295740ec, timeout=0x0, alertable=0)
> | at handles.c:1490
> | #4 0x081915c6 in _wapi_handle_timedwait_signal_handle (handle=0x5804,
> timeout=0x0, alertable=0)
> | at handles.c:1570
> | #5 0x081913cc in _wapi_handle_wait_signal_handle (handle=0x5804,
> alertable=0) at handles.c:1530
> | #6 0x081afbf8 in WaitForSingleObjectEx (handle=0x5804, timeout=4294967295,
> alertable=0) at wait.c:205
> | #7 0x0810182f in finalizer_thread (unused=0x0) at gc.c:908
> | #8 0x08122d52 in start_wrapper (data=0x2956f960) at threads.c:621
> | #9 0x081a9d8a in thread_start_routine (args=0x295741d4) at threads.c:279
> | #10 0x081cd98e in GC_start_routine (arg=0x832bec0) at pthread_support.c:1382
> | #11 0x286a5865 in thread_start (curthread=0x29564c00) at
> /usr/src/lib/libthr/thread/thr_create.c:256
> | #12 0x in ?? ()
> | Current language: auto; currently asm
> |
> | Thread 3 (Thread 0x29564100 (LWP 100388)):
> | #0 0x28769f53 in nanosleep () at nanosleep.S:2
> | #1 0x286a47e2 in __nanosleep (time_to_sleep=0xbf9fef8c, time_remaining=0x0)
> | at /usr/src/lib/libthr/thread/thr_syscalls.c:306
> | #2 0x0818bcf5 in collection_thread (unused=0x0) at collection.c:34
> | #3 0x286a5865 in thread_start (curthread=0x29564100) at
> /usr/src/lib/libthr/thread/thr_create.c:256
> | #4 0x in ?? ()
> |
> | Thread 2 (Thread 0x29501100 (LWP 100408)):
> | #0 0x294dc2d3 in ?? ()
> | #1 0xbfbfe774 in ?? ()
> | #2 0xbfbfe474 in ?? ()
> | #3 0x in ?? ()
> | #4 0x in ?? ()
> | #5 0x in ?? ()
> | #6 0x0001 in ?? ()
> | #7 0x in ?? ()
> | #8 0x2951903c in ?? ()
> | #9 0xbfbfe458 in ?? ()
> | #10 0xbfbfe474 in ?? ()
> | #11 0xbfbfe774 in ?? ()
> | ---Type to continue, or q to quit---
> | #12 0x000a in ?? ()
> | #13 0xbfbfe474 in ?? ()
> | #14 0x294dc259 in ?? ()
> | #15 0x in ?? ()
> | #16 0x in ?? ()
> | #17 0xbfbfe498 in ?? ()
> | #18 0x294dc1b7 in ?? ()
> | #19 0x080d935e in mono_custom_attrs_from_index (image=0x0, idx=0) at
> reflection.c:7730
> | Previous frame inner to this frame (corrupt stack?)
> | (gdb)
>
> With regards,
> Romain
>
> References:
> 1.
> http://code.google.com/p/bsd-sharp/source/browse/trunk/lang/mono/files/patch-configure
>
WBR, MoKo
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
