[Gc] GC segfault on ARM

Boehm, Hans hans.boehm at hp.com
Wed Aug 17 15:38:04 PDT 2005

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?)


> -----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 
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list