GC failure on alpha-linux

Mon Dec 10 09:50:00 GMT 2001

I assume GC_data_start is remains 0 in all cases? 
Is __data_start defined by the linker or libc? (If it really doesn't get to
GC_init_linux_data_start it doesn't matter. But it sounds like gdb
breakpoints might not be 100% reliable? Might there be a buffering issue
with the fprintf if the process is run under gdb?)
Is GC_is_initialized set before the collector is first invoked? Could this
be an initialization ordering problem? If so, it would be nice to
understand how it got into the collector without initializing itself.
Hans
> -----Original Message-----
> From: Jeff Sturm [mailto:jsturm@one-point.com]
> Sent: Sunday, December 09, 2001 9:01 PM
> To: java@gcc.gnu.org
> Subject: GC failure on alpha-linux
>>> I've been getting failures on the trunk for the last few 
> weeks. I'm at a
> loss on how to debug it though:
>> (gdb) r
> Starting program: /home/jsturm/hello 
> [New Thread 1024 (runnable)]
>> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (runnable)]
> 0x200000555dc in GC_mark_from_mark_stack () at 
> ../../../boehm-gc/mark.c:584
> 584	../../../boehm-gc/mark.c: No such file or directory.
> 	in ../../../boehm-gc/mark.c
> (gdb) print GC_data_start
> No symbol "GC_data_start" in current context.
> (gdb) call GC_print_static_roots()
> From 0x0 to 0x120011500 
> ^^^
> Clearly this is wrong. I added a fprintf(...) statement to
> GC_init_linux_data_start to get an idea what's happening, and it looks
> normal when run from the command line. But when running inside the
> debugger, it prints nothing, and never even seems to call
> GC_init_linux_data_start! (I tried a breakpoint, and didn't 
> see the usual
> stop on SIGSEGV.)
>> Next I tried reading the core file from "hello". But gdb 
> refuses to load
> a core file from a multithreaded executable.
>> Any ideas before I resume hitting my head against a wall?
>> Jeff
>