RE: SIGSEGV in GC_mark_from

["Boehm, Hans" <hans_boehm at hp dot com>]

I assume this is the trunk?

It looks to me like the descriptor is the root cause of the problems.  The
object base address current_p is probably valid.  The descriptor ends in
zero bits, so it's interpreted as an object length.  The length and
current_p are added, and the collector starts to look for pointers there.
Somehow a pointer made it into the descriptor slot, and things go downhill
from there.

You might check that current_p points to an object which is properly
described, i.e. has a pointer to a proper vtable.

Failing that, probably the only real way to debug this is to insert code
that looks for absurd descriptors at various places, i.e. anything huge with
the 4 low order bits zero.  I would start by inserting such a test around
line 622.

Hans

> -----Original Message-----
> From: Jeff Sturm [mailto:jsturm@one-point.com]
> Sent: Wednesday, September 05, 2001 2:45 PM
> To: java@gcc.gnu.org
> Subject: SIGSEGV in GC_mark_from
> 
> 
> 
> Here's what I'm puzzling over today:
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 17 (LWP 3)]
> GC_mark_from (mark_stack_top=0xfd7c57f8, mark_stack=0xfd7b0000, 
>     mark_stack_limit=0xfd7d0000) at ../../../boehm-gc/mark.c:654
> 654               deferred = *limit;
> 
> This is reproducible but not deterministic.  "limit" looks like a
> legal address but doesn't seem to be mapped:
> 
> (gdb) print limit
> $1 = (word *) 0xfe8780b0
> 
> (gdb) call GC_print_heap_sects()
> Total heap size: 16662528
> Section 0 from 0xfe940000 to 0xfe950000 0/16 blacklisted
> Section 1 from 0xfe8e0000 to 0xfe8f0000 0/16 blacklisted
> Section 2 from 0xfe8c0000 to 0xfe8d0000 0/16 blacklisted
> Section 3 from 0xfe880000 to 0xfe892000 0/18 blacklisted
> Section 4 from 0xfe860000 to 0xfe878000 0/24 blacklisted
> ...
> 
> The descriptor doesn't look right either:
> 
> (gdb) print (void *)descr
> $37 = (void *) 0xfd355af0
> 
> Any ideas?  This is on sparc-sun-solaris2.7.
> 
> Jeff
> 
>