[Bug libgcj/18266] GCJ: Using references drops finalizers causing all apps to eventually crash ( SIGSEGV in GC_register_finalizer_inner () )

["daney at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #20 from daney at gcc dot gnu dot org  2008-09-26 15:58 -------

1) Create an object.

2) Enter a synchronized block on the object and do Object.wait().

3) In a second thread, enter a synchronized block on the object.  There is lock
contention, heavy lock escalation is guaranteed.  Hash synchronization code
registers a finalizer recording the old finalizer.  The old finalizer is null
as no finzlizers have been registered for the object.

4) Create a WeakReference to the Object.  This adds a finalizer, overwriting
and thus losing the Hash synchronization's finalizer.

5) Both threads leave the synchronized block.  At this point the heavy_lock
object in the hash synchronization code in no longer in use and is eligible for
clean up.

6) Many other locks are acquired and released, some of these hash to the same
value as the lock used in steps 1 and 2.  Eventually the hash row for these
locks is cleaned up.  The clean up code restores the saved finalizer from step
3 which was null, thus overwriting the WeakReference's finalizer.

7) WeakReference's referent is GCed, but its finalizer has been removed in step
6, so it does not get cleaned up.

If you ever synchronize o the If the object itself is a WeakReference, the same
thing happens, but ref->enqueue is called on the WeakReference.  If A different
type of object has been allocated in the WeakReference's previous location,
when  the referent is finalized ref->enqueue will be called through the vtable
of the new object resulting sometimes in SIGSEGV or other types of bad
behavior.  


-- 


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