RE: gc crash caused by improper use of GC_general_register_disappearing_link

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

The GC interface is a bit inconsistent here.  I changed the
finalizer registration interface to explicitly disregard requests
to register a finalizer for static data (gcj does that, too),
but I didn't change the disappearing link one.

The way the code currently works, it is cheap to do this in the
finalizer case (a null test after a block header lookup), but requires
extra work in the disappearing link case, since the header lookup
isn't otherwise being performed.  But it might independently
make sense to do the header lookup in both cases, and cache the
header address.

Thus I could go either way on having the GC or libgcj do this
check.  (It seems equally clean either way.  Since static objects
don't become unreachable, these calls should logically be no-ops.
Having the two work inconsistently is not ideal, though.)

A quick fix would be to have libgcj check GC_base(<pointer>)!=0
before registering the pointer.  A faster but uglier way is to
use GC_find_header() instead of GC_base().

We could use GC_find_header as a stopgap, and have GC7 do the
right thing.

Hans

> -----Original Message-----
> From: Andrew Haley [mailto:aph@redhat.com]
> Sent: Friday, November 12, 2004 10:34 AM
> To: Boehm, Hans
> Cc: java@gcc.gnu.org
> Subject: gc crash caused by improper use of
> GC_general_register_disappearing_link
> 
> 
> I had a crash inside the gc.  It turns out that someone made a weak
> reference to an instance of class Class.  However, some instances of
> Class are statically allocated, and the doc for
> GC_general_register_disappearing_link says
> 
> "Obj must be a pointer to the first word of an object we allocated."
> 
> So, this call to GC_general_register_disappearing_link is illegal.  
> 
> Is there some reasonably easy way we can do something like
> 
>   if (thing points to something that is gc allocated)
>      GC_general_register_disappearing_link(thing)
> 
> We intend to heap allocate instances of Class in the future, but I'd
> prefer not to have to do so right now.
> 
> Thanks,
> Andrew.
>