[Bug libgcj/18266] SIGSEGV in GC_register_finalizer_inner ()

["Hans dot Boehm at hp dot com" <gcc-bugzilla@gcc.gnu.org>]

------- Additional Comments From Hans dot Boehm at hp dot com  2004-11-08 19:55 -------
I think this could be explained by the same problem.

This time the collector is in the Java-specific finalization pass which
marks objects reachable from objects that are about to be finalized,
so that the finalizer doesn't see deallocated memory.

It appears that the finalizable object it's marking from has somehow
been clobbered already, and no longer has a proper vtable entry.
Hence the collector dies trying to find the mark descriptor in the
vtable.

I can see how this might happen if we accidentally register a finalizer
on something that was already collected, which can happen if the
finalizer installed by hash synchronization is dropped.

It might be useful to find a little more of the context.  Try

p descr
p current_p
p type_descr
p GC_gc_no
p *mark_stack_top
up 1		-- goto GC_finalize frame
p real_ptr
p *curr_fo
x/8wx real_ptr -4

Printing *curr_fo should indicate the finalization function and "client data"
associated with this object.  It would be useful to explore the "client data"
a bit further, so that we can understand what the finalizer is really trying to 
do.
(All Java finalizers use the same function, and use the client data field to
specify what really needs to be done.)

Assuming current_p and real_ptr are the same, and you can call functions
from gdb, try

p GC_find_header(real_ptr)

If that looks like a sane pointer, also try 

p *GC_find_header(real_ptr)
p GC_base(real_ptr)

I need to look at the WeakHashMap code, but I won't get a chance to do that
for a few days.

We could also probably track this down more systematically by
having the hash synchronization code check that the vtable pointer hasn't
changed when we reregister the client finalizer around line 757 in natObject.cc.
We would have to remember the vtable pointer in the hl structure.
This might cause this to fail far more predictably, and might at
least confirm that we're not barking up the wrong tree.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266