[Gc] segfault on arm

Boehm, Hans hans.boehm at hp.com
Wed Jul 27 10:54:02 PDT 2005


What's the value of limit?  What address is it trying to access?

I expect that the position of either the main data segment or stack
changed recently, and it's trying to trace from a now nonexistent
location.

If I had to make a really wild guess, I'd suggest defining
LINUX_STACKBOTTOM instead of HEURISTIC1 (and STACK_GRAN) in
the ARM32/LINUX section in gcconfig.h.  But then the comment
next to the DATASTART definition in the same file starts with
"hideous kludge:", so that might also be worth checking.

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Christian Thalinger
> Sent: Wednesday, July 27, 2005 7:30 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] segfault on arm
> 
> 
> Hi!
> 
> We are currently porting CACAO to the arm architecture and it 
> seems there is problem with the gc. Simply running the gc 
> test results in:
> 
> twisti at arm-linux:~/cacao/boehm-gc/gc6.5$ ./config.guess 
> armv4tl-unknown-linux-gnu 
> twisti at arm-linux:~/cacao/boehm-gc/gc6.5$ 
> LD_LIBRARY_PATH=.libs/ gdb .libs/gctest 
> GNU gdb 6.3-debian
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public 
> License, and you are welcome to change it and/or distribute 
> copies of it under certain conditions. Type "show copying" to 
> see the conditions. There is absolutely no warranty for GDB.  
> Type "show warranty" for details. This GDB was configured as 
> "arm-linux"...Using host libthread_db library 
> "/lib/libthread_db.so.1".
> 
> (gdb) r
> Starting program: /nfs/a5/twisti/cacao/boehm-gc/gc6.5/.libs/gctest 
> 
> Program received signal SIGSEGV, Segmentation fault. 
> GC_mark_from (mark_stack_top=0x2a0e0, mark_stack=0x2a0a8,
> mark_stack_limit=0x320a8) at mark.c:759
> 759               deferred = *limit;
> (gdb) bt
> #0  GC_mark_from (mark_stack_top=0x2a0e0, mark_stack=0x2a0a8,
> mark_stack_limit=0x320a8) at mark.c:759
> #1  0x4002bbb8 in GC_mark_some (cold_gc_frame=0xbefffa5c 
> ",C\001") at mark.c:326 #2  0x400258dc in GC_stopped_mark 
> (stop_func=0x40024ee4
> <GC_never_stop_func>) at alloc.c:531
> #3  0x400254e0 in GC_try_to_collect_inner (stop_func=0x40024ee4
> <GC_never_stop_func>) at alloc.c:378
> #4  0x4002ebac in GC_init_inner () at misc.c:782
> #5  0x4002aa20 in GC_generic_malloc_inner (lb=7, k=1) at 
> malloc.c:125 #6  0x4002ab7c in GC_generic_malloc (lb=7, k=1) 
> at malloc.c:192 #7  0x4002ad9c in GC_malloc (lb=52) at 
> malloc.c:311 #8  0x0000a220 in run_one_test () at 
> tests/test.c:1218 #9  0x0000ab78 in main () at tests/test.c:1521
> (gdb) 
> 
> The same happens with gij-3.4 (i have no newer version 
> handy). Any idea?
> 
> TWISTI
> _______________________________________________
> 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