[Gc] GC segfault on ARM

Brian Koropoff briank at marakicorp.com
Thu Aug 18 12:31:10 PDT 2005


This appears to have been the issue.  I changed HEURISTIC1 to 
LINUX_STACKBOTTOM in the ARM Linux section of gcconfig.h and Mono no 
longer segfaults.  Thank you for your help.  I'll let the Mono 
developers know that they should merge this upstream change.

Brian

Boehm, Hans wrote:

>Could this be the same issue that was already fixed in my tree?
>LINUX/ARM should define LINUX_STACKBOTTOM in gcconfig.h instead
>of trying to explicitly determine a stack base.
>
>I'm a little concerned that it appears to be the value of bottom here
>that's clearly wrong.  That should presumably be the current stack
>pointer?  Is it somehow not getting set correctly?
>
>I think this code is slightly modified for Mono, so it would be
>good to identify where exactly the 0 value of bottom is coming from.
>(Presumably p is zero when this fails?)
>
>Hans
>
>  
>
>>-----Original Message-----
>>From: gc-bounces at napali.hpl.hp.com 
>>[mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Brian Koropoff
>>Sent: Wednesday, August 17, 2005 2:02 PM
>>To: gc at napali.hpl.hp.com
>>Cc: Krishna Ganugapati; Paolo Molaro
>>Subject: [Gc] GC segfault on ARM
>>
>>
>>While attempting to run the Mono .NET implementation on an ARM linux 
>>system, I encountered a segmentation fault almost immediately upon 
>>program startup.  A backtrace indicates that it occurs in the garbage 
>>collector:
>>
>>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?)
>>
>>Since the segfault could be caused by another part of Mono 
>>corrupting GC 
>>data structures, I've also contacted the Mono development list about 
>>this issue.  The system in question is an IXDPG425 reference 
>>board from 
>>Intel with an ARM V5T (XScale) processor running linux 2.6 in 
>>big endian 
>>mode.  The system uses glibc compiled with LinuxThreads 
>>thread support.  
>>If there is anything in particular that I should investigate 
>>as being a 
>>possible cause, or any further information I could provide that might 
>>help diagnose the problem, please let me know.
>>
>>Regards,
>>Brian Koropoff
>>_______________________________________________
>>Gc mailing list
>>Gc at linux.hpl.hp.com 
>>http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>>
>>    
>>



More information about the Gc mailing list