[Bug libgcj/18266] SIGSEGV in GC_register_finalizer_inner ()
------- Additional Comments From Hans dot Boehm at hp dot com 2005-06-09 05:10 -------
Unfortunately, I haven't had time to pursue this.
I think that in order to get this to fail, you want lots of weak references to
objects which are also sobject to lock contention or wait/notify calls. I don't
think we currently have a good test case.
My impression is that natReference.cc already keeps a fairly elaborate data
structure to which you should be able to add the prior finalization info, so
that it can be invoked at the right point by the existing finalizer there.
In general, the GC's data structures don't queue multiple finalizers. You need
to register a new finalizer that knows it has to reregister the old one when
it's done. The information that there was another finalizer needs to be kept
off to the side somewhere in a separate table, or as part of the "client data"
registered with the finalizer. The locking code also has to deal with opaque
objects, but it again has its own hash table off to the side.