Mono 2.0 and FreeBSD

[Romain Tartière]

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 0x00000000 in ?? ()
> #4 0x00000000 in ?? ()
> #5 0x00000000 in ?? ()
> #6 0x00000001 in ?? ()
> #7 0x00000000 in ?? ()
... which I don't think is good (too much 0x00000000)...

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 <rom...@blogreen.org> 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)

[Romain Tartière]

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 <signal handler called>
#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 <signal handler called>
#10 0x299a22db in ?? ()
#11 0xbfbfe804 in ?? ()
#12 0xbfbfe4f4 in ?? ()
#13 0x00000000 in ?? ()
#14 0x00000000 in ?? ()
#15 0x00000000 in ?? ()
#16 0x00000001 in ?? ()
#17 0x00000000 in ?? ()
#18 0x2951903c in ?? ()
#19 0xbfbfe4d8 in ?? ()
#20 0xbfbfe4f4 in ?? ()
#21 0xbfbfe804 in ?? ()
#22 0x0000000a in ?? ()
#23 0xbfbfe4f4 in ?? ()
#24 0x299a2261 in ?? ()
#25 0x00000000 in ?? ()
#26 0x00000000 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

[Paul Hoffman]

Thanks for taking this on, Romain. You probably saw my earlier messages on the bsd-sharp mailing list about a2c failing under Mono 2 under FreeBSD. This caused at least one project that was going to use a2c to now shun it. If we can fix this issue, it would help greatly.

[Romain Tartière]

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]

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 0x00000000 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 0x00000000 in ?? ()
|

| Thread 2 (Thread 0x29501100 (LWP 100408)):
| #0 0x294dc2d3 in ?? ()
| #1 0xbfbfe774 in ?? ()
| #2 0xbfbfe474 in ?? ()

| #3 0x00000000 in ?? ()
| #4 0x00000000 in ?? ()
| #5 0x00000000 in ?? ()
| #6 0x00000001 in ?? ()
| #7 0x00000000 in ?? ()

| #8 0x2951903c in ?? ()
| #9 0xbfbfe458 in ?? ()
| #10 0xbfbfe474 in ?? ()
| #11 0xbfbfe774 in ?? ()
| ---Type <return> to continue, or q <return> to quit---
| #12 0x0000000a in ?? ()
| #13 0xbfbfe474 in ?? ()
| #14 0x294dc259 in ?? ()

| #15 0x00000000 in ?? ()

| #16 0x00000000 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

[Zoltan Varga]

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 <rom...@blogreen.org>:

> _______________________________________________
> Mono-devel-list mailing list
> Mono-de...@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>

[Geoff Norton]

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

[Geoff Norton]

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

[Konstantin Morshnev]

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

> ------------------------------------------------------------------------

WBR, MoKo

[Geoff Norton]

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

[Geoff Norton]

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:

[Phillip N.]

El mar, 09-12-2008 a las 12:57 +0100, Romain Tartière escribió:
> I have just discovered that a patch in the FreeBSD port remove the
> explicit activation of sigaltstack [1].

It looks that what it does, is let configure decide, if to use it or
not.
Reading the comments, it seems that a more usefull value should be no,
so ive change the FreeBSD-ports Makefile to call configure using
--with-signaltstack=no by default.

El mar, 09-12-2008 a las 19:01 +0300, Konstantin Morshnev escribió:
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

I guess you mean mini.c :)

Greate! adding that let the test pass ok, i can confirm that.

Now, the only test that is failing is:

pinvoke2.exe

Ill add the MONO_ARCH_SIGSEGV_ON_ALTSTACK in the freebsd ports and start
again to test the programs that were failing

Thanks all!

good luck!

[Phillip N.]

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!

[Romain Tartière]

On Tue, Dec 09, 2008 at 02:51:04PM -0300, Phillip N. wrote:
>
> El mar, 09-12-2008 a las 12:57 +0100, Romain Tartière escribió:
> > I have just discovered that a patch in the FreeBSD port remove the
> > explicit activation of sigaltstack [1].
> It looks that what it does, is let configure decide, if to use it or
> not.
> Reading the comments, it seems that a more usefull value should be no,
> so ive change the FreeBSD-ports Makefile to call configure using
> --with-signaltstack=no by default.

I agree, this is better this way :-)

> El mar, 09-12-2008 a las 19:01 +0300, Konstantin Morshnev escribió:
> 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
>
>
> I guess you mean mini.c :)
>
> Greate! adding that let the test pass ok, i can confirm that.

...err ... it's not working better here :-( (checkout of subversion
repository of BSD# at revision 172 with the patch)

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. A diff
between the GENERIC kenel and my local configuration is available [1],
along with a list of module I use [2] and my sysctl.conf file [3], in
case somebody sees something obvious.

Regards,
Romain

References:
1. http://mono.sigabrt.org/kernel-config.diff
2. http://mono.sigabrt.org/kldstat
3. http://mono.sigabrt.org/sysctl.conf

[Romain Tartière]

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 ro...@marvin.blogreen.org:/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

[Phillip N.]

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!)

Currently, on amd64 things seem to work quite fine.

On the other side, often on i386 i see the following message:

"Thread 8363c00 has exited with leftover thread-specific data after 4
destructor iterations"

This is not "mortal" as things works out fine. For example Velocity or
FSpot works ok (i could not run before the modification to mini.c).

Some time ago i reported this on the amd64 architecture, wich no longer
has the problem: https://bugzilla.novell.com/show_bug.cgi?id=323290
This bug could be close. At least for me, things works fine on amd64.

But, the same is present on i386 now.
Can this be related to that on i386 --with-signaltstack=no, things
doesnt work?
Could i report more details, to help fix this i386 problem?

Bugs related to this, that from my point of view, could be closed:
https://bugzilla.novell.com/show_bug.cgi?id=349054
https://bugzilla.novell.com/show_bug.cgi?id=448131
https://bugzilla.novell.com/show_bug.cgi?id=376618

Thanks!

[killfill@flash ~]$ mono -V
Mono JIT compiler version 2.0.1 (tarball)
Copyright (C) 2002-2008 Novell, Inc and Contributors.
www.mono-project.com
TLS: __thread
GC: Included Boehm (with typed GC)
SIGSEGV: normal
Notification: Thread + polling
Architecture: amd64
Disabled: none

[killfill@pcbsd ~]$ mono -V
Mono JIT compiler version 2.0.1 (tarball)
Copyright (C) 2002-2008 Novell, Inc and Contributors.
www.mono-project.com
TLS: __thread
GC: Included Boehm (with typed GC)
SIGSEGV: altstack
Notification: Thread + polling
Architecture: x86
Disabled: none

[Romain Tartière]

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 !