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