gcc-3.1 2002年04月03日 libjava failures on sparc-linux?

Tue Apr 9 23:39:00 GMT 2002

> -----Original Message-----
> From: Christian Jönsson [mailto:c.christian.joensson@telia.com]
> (gdb) r
> Starting program: 
> /share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/sparc-linux/l
> ibjava/testsuite/cxxtest 
>> Program received signal SIGSEGV, Segmentation fault.
> 0x506d6f60 in GC_push_all_eager (bottom=0xeaffe3d4 "P0022円H@", 
> top=0xf0000000 <Address 0xf0000000 out of bounds>)
> at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
> 1349		q = *p;
> (gdb) bt
> #0 0x506d6f60 in GC_push_all_eager (bottom=0xeaffe3d4 "P0022円H@", 
> top=0xf0000000 <Address 0xf0000000 out of bounds>)
> at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
> #1 0x506d7058 in GC_push_all_stack_partially_eager (
> bottom=0xeaffe3d4 "P0022円H@", 
> top=0xf0000000 <Address 0xf0000000 out of bounds>, 
> cold_gc_frame=0xeaffe5bc "") at 
> /share2/gcc-rel/gcc/boehm-gc/mark.c:1386

This is actually rather suggestive. It was trying to mark a stack between
0xeaffe3d4 and 0xf0000000. That's a big stack. I suspect one of the
following:
1) Java is compiled with thread support, but the collector gets configures
without GC_LINUX_THREADS defined. Thus it's trying to mark between a thread
stack pointer and the base of the main stack.
2) The default stack base of (specified in gcconfig.h) of 0xf0000000 is
wrong on your machine. Try stopping a toy program in main and print $sp
from gdb to see whether the stack base looks plausible.
Hans