[Mono-dev] Re: GC segfault on ARM
IT2003_1: Morenz, Tino
TinoMorenz at ba-glauchau.de
Thu Aug 18 09:34:55 EDT 2005
Hi,
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 32700)]
> GC_push_all_eager (bottom=0x0, top=0x1990a8 "") at mark.c:1468
> 1468 q = *p;
> (gdb) bt
> #0 GC_push_all_eager (bottom=0x0, top=0x1990a8 "") at mark.c:1468
> #1 0x000b9ef8 in pthread_push_all_stacks () at pthread_stop_world.c:266
> #2 0x000b9fac in GC_push_all_stacks () at pthread_stop_world.c:297
> #3 0x000b5848 in GC_push_roots (all=1, cold_gc_frame=0xbefffa4c "")
> at mark_rts.c:643
> #4 0x000b4c60 in $a () at mark.c:326
> #5 0x000b4c60 in $a () at mark.c:326
> Previous frame identical to this frame (corrupt stack?)
I get the same error on a x86 box running QNX.
Basically all I can say is that q is supposed to be an address in your stack which is actually readable. So if you can determin your process' stack range by using any other tools you can check whether q is still a valid part of your stack.
The problem in my case are so called 'guard pages'. That's what QNX help say about them:
****
At the end of each virtual stack is a guard page that the microkernel
uses to detect stack overflows. If your program writes to an address
within the guard page, the microkernel detects the error and sends the
process a SIGSEGV signal.
****
And it's actually weven worse: not oly writing to but also reading fr4om a guard page leads to SIGSEGV.
So when the GC is scanning through the stack starting at STACKBOTTOM and it comes to a guard page and subsequently SIGSEGVs when trying to read the content of it (i.e.*q fails allthought q seems to be a reasonable address).
More information about the Mono-devel-list
mailing list