[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