[Mono-list] mono on debian/powerpc && openbsd/i386

christophe barbe christophe@cattlegrid.net
Tue, 2 Mar 2004 14:29:44 -0500


On Tue, Mar 02, 2004 at 08:03:03PM +0100, Andras GELANYI wrote:
> i have the same problem under openbsd..
> 
> after a little cpuid hack (disabled cpuid usage) i successfully compiled
> mono 0.30.2 on my openbsd3.4 box (arch i386).

I am surprised, I expected the problem to be on non-x86 archs.

> mono --help works. but when i try to run any bytecode with mono it
> produces the same as cristophe wrote.

You are right it's a mono problem not a mcs problem.

> using gdb i figured out that the segmentation fault is in the
> GC_find_limit function. (maybe the segfault signal handling is wrong and
> then comes the deadlock.)
> 
> can anyone help me to solve this problem?
> 
> the gdb output:
> 
> ------------------------------------------------------------------------
> GNU gdb 4.16.1
> Copyright 1996 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-unknown-openbsd3.4"...
> (gdb) run /home/ghz/mono/bin/mcs.exe hello.cs
> Starting program: /home/ghz/mono/bin/mono /home/ghz/mono/bin/mcs.exe
> hello.cs
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x7179ab5 in GC_find_limit (p=0x3c003160 "?f??", up=0) at os_dep.c:806
> 806                     GC_noop1((word)(*result));
> (gdb) bt
> #0  0x7179ab5 in GC_find_limit (p=0x3c003160 "?f??", up=0) at
> os_dep.c:806
> #1  0x71798fc in GC_init_netbsd_elf () at os_dep.c:390
> #2  0x7178c8a in GC_init_inner () at misc.c:639
> #3  0x7175585 in GC_generic_malloc_inner (lb=28, k=1) at malloc.c:123
> #4  0x71756a5 in GC_generic_malloc (lb=28, k=1) at malloc.c:190
> #5  0x7175856 in GC_malloc (lb=28) at malloc.c:295
> #6  0x7169133 in mono_g_hash_table_new_full (hash_func=0xd25ef40
> <g_direct_hash>, key_equal_func=0xd25ef48 <g_direct_equal>,
>     key_destroy_func=0, value_destroy_func=0) at mono-hash.c:152
> #7  0x716910c in mono_g_hash_table_new (hash_func=0xd25ef40
> <g_direct_hash>, key_equal_func=0xd25ef48 <g_direct_equal>) at
> mono-hash.c:122
> #8  0x716838b in TlsSetValue (idx=0, value=0x3c0070d0) at threads.c:801
> #9  0x70e4f3d in setup_jit_tls_data (stack_start=0xffffffff,
> abort_func=0x70e4ef4) at mini.c:6341
> #10 0x70e78a8 in mini_init (filename=0xcfbf6834
> "/home/ghz/mono/bin/mcs.exe") at mini.c:7873
> #11 0x7100797 in mono_main (argc=3, argv=0xcfbf66d4) at driver.c:677
> #12 0x1c000757 in main (argc=3, argv=0xcfbf66d4) at main.c:6
> #13 0x1c000691 in ___start ()
> #14 0x1c000607 in __start ()
> #15 0xcfbf681c in ?? ()
> Error accessing memory address 0x3: Invalid argument.
> (gdb) c
> Continuing.
> ^C
> Program received signal SIGINT, Interrupt.
> 0x7179ab5 in GC_find_limit (p=0xcfbf6400
> "??\r'$\020\016'(d??(\216\027\a\027\001", up=1) at os_dep.c:806
> 806                     GC_noop1((word)(*result));
> (gdb) c
> Continuing.
> ^C
> Program received signal SIGINT, Interrupt.
> 0x7179ab5 in GC_find_limit (p=0xcfbf6400
> "??\r'$\020\016'(d??(\216\027\a\027\001", up=1) at os_dep.c:806
> 806                     GC_noop1((word)(*result));
> ------------------------------------------------------------------------

-- 
Christophe Barbé <christophe.barbe@ufies.org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

In theory there is no difference between theory and practice. In
practice there is. -- Yogi Berra