[Gc] GC segfault on ARM
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
> 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.
> Brian Koropoff
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc