Re: mono core dumping on current

[Patrick Welche <prlw1%cam.ac.uk@localhost>]

On Mon, Mar 05, 2012 at 10:57:31PM +0100, Thomas Klausner wrote:
> On 6.99.3/amd64, I have trouble with a few mono packages that built
> fine on 5.99.64.
> 
> I've tried rebuilding mono, and this also fails now.
> with CFLAGS=-g -O0 I get the following backtrace for the core dump during the 
> build:
> [New process 2]
...
> Core was generated by `mono'.
> Program terminated with signal 6, Aborted.
> #0  0x00007f7ff70ed9da in _lwp_kill () from /usr/lib/libc.so.12
> (gdb) bt
> #0  0x00007f7ff70ed9da in _lwp_kill () from /usr/lib/libc.so.12
> #1  0x00007f7ff70ed312 in abort () at 
> /archive/cvs/src/lib/libc/stdlib/abort.c:74
> #2  0x00000000004d7de5 in mono_handle_native_sigsegv (signal=11, 
> ctx=0x7f7fffffb3e0) at mini-exceptions.c:2245
> #3  0x0000000000420685 in mono_sigsegv_signal_handler (_dummy=11, 
> info=0x7f7fffffb360, context=0x7f7fffffb3e0) at mini.c:5848
> #4  <signal handler called>
> #5  GC_push_all_eager (bottom=0x7f7fffffb7e8 "?\377\377\177\177", 
> top=0x7f8008000000 <Address 0x7f8008000000 out of bounds>) at mark.c:1468
> #6  0x00000000006b3fa8 in GC_push_all_stack (bottom=0x7f7fffffb7e8 
> "?\377\377\177\177", top=0x7f8008000000 <Address 0x7f8008000000 out of 
> bounds>) at mark.c:1521
> #7  0x00000000006bbecd in pthread_push_all_stacks () at 
> pthread_stop_world.c:297
> #8  0x00000000006bbf49 in GC_push_all_stacks () at pthread_stop_world.c:332
> #9  0x00000000006b71d2 in GC_default_push_other_roots () at os_dep.c:2255
> #10 0x00000000006b53ac in GC_push_roots (all=1, cold_gc_frame=0x7f7fffffb8e4 
> "\177\177") at mark_rts.c:646
> #11 0x00000000006b1dd7 in GC_mark_some (cold_gc_frame=0x7f7fffffb8e4 
> "\177\177") at mark.c:326
> #12 0x00000000006abe0a in GC_stopped_mark (stop_func=0x6ab387 
> <GC_never_stop_func>) at alloc.c:543
> #13 0x00000000006ab9eb in GC_try_to_collect_inner (stop_func=0x6ab387 
> <GC_never_stop_func>) at alloc.c:382
> #14 0x00000000006b5d6e in GC_init_inner () at misc.c:807
> #15 0x00000000006b596b in GC_init () at misc.c:517
> #16 0x0000000000574bbc in mono_gc_base_init () at boehm-gc.c:126
> #17 0x0000000000598d30 in mono_init_internal (filename=0x7f7fffffe428 
> ".//class/lib/monolite/mcs.exe", exe_filename=0x7f7fffffe428 
> ".//class/lib/monolite/mcs.exe", runtime_version=0x0) at domain.c:1286
> #18 0x000000000059a0a1 in mono_init_from_assembly (domain_name=0x7f7fffffe428 
> ".//class/lib/monolite/mcs.exe", filename=0x7f7fffffe428 
> ".//class/lib/monolite/mcs.exe") at domain.c:1671
> #19 0x000000000042140a in mini_init (filename=0x7f7fffffe428 
> ".//class/lib/monolite/mcs.exe", runtime_version=0x0) at mini.c:6321
> #20 0x00000000004ad44b in mono_main (argc=7, argv=0x7f7fffffbdb8) at 
> driver.c:1746
> #21 0x0000000000412d8e in mono_main_with_options (argc=7, 
> argv=0x7f7fffffbdb8) at main.c:66
> #22 0x0000000000412dbe in main (argc=7, argv=0x7f7fffffbdb8) at main.c:97
> 
> Can someone make something of this?

That looks like the same backtrace as PR 45828 in which Noud traces the
problem to the configured garbage collector...

Cheers,

Patrick