------- 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
