[Bug libgcj/18266] SIGSEGV in GC_register_finalizer_inner ()

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

------- Additional Comments From Hans dot Boehm at hp dot com  2004-11-01 20:44 -------
This would be a lot easier if libgcj had been built with something like -O2 -g.

Based on approximate manual matching of the object code to finalize.s, I think 
this is failing around line 452 of finalize.c on the line

new_fo -> fo_object_size = hhdr -> hb_sz;

It appears that hhdr is in %edx and is 1.  This can occur if the first argument 
to GC_register_finalizer_inner is a pointer to somewhere in the second page of 
a large object.  It should of course be a base pointer to an object, so this 
should be impossible.

I think the GC_register_finalizer_no_order call must be coming from 
maybe_remove_all_heavy(), which called remove_all_heavy, which was presumably 
inlined into _Jv_MonitorExit().  I see no other path to 
GC_register_finalizer_no_order().

That makes it appear that an object whose heavy-weight lock we are about to 
remove has previously been garbage collected.  That should be impossible since 
we previously registered our own finalizer for the object in question, and that 
acquires the lock bit in the lock hash table entry, as does remove_all_heavy.  
Thus the finalizer should have previously been run to completion, and all 
traces of the heavy lock should have been previously removed.

Are there places we add a finalizer to an existing object without checking for 
prior finalizers?  That might explain the problem.

We really need some more evidence to confirm this chain of reasoning.  A -g 
stack trace, and the values of the finalization proc and data (and the object 
the data pointer points to, if any) that are being passed to 
GC_register_finalizer_inner might help.  So would GC_find_header
(object_being_registered_address).  Assuming that's one, as expected, then 
*GC_find_header(object_being_registered_address - 4096) together with GC_gc_no 
would also be somewhat interesting.

Does this application use some flavor of weak references?  If so, which one?

-- 


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