[Bug libgcj/18266] SIGSEGV in GC_register_finalizer_inner ()

[Bug libgcj/18266] SIGSEGV in GC_register_finalizer_inner ()

[tromey at gcc dot gnu dot org]

------- Comment #14 from tromey at gcc dot gnu dot org  2006-03-08 19:27 -------
I've been looking into this a bit.

The current problem I see is that the heavyweight lock stuff
relies on the GC.  This won't interact well with the current
code in natReference.cc, as those data structures are not scanned.

Also, I do think that both calls to _Jv_RegisterFinalizer in
Reference::create are problematic.  The first call registers a finalizer
for the Reference, the second for the referent.  But, there is nothing
preventing a subclass of Reference from having a finalizer; or from
user code acquiring a heavy lock on a Reference object.  So, all
cases have to be handled here.


-- 


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

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

[r_ovidius at eml dot cc]

------- Comment #15 from r_ovidius at eml dot cc  2006-11-03 22:58 -------
Updated summary.  (Happy 2 year birthday, stupid stubborn bug.)


-- 

r_ovidius at eml dot cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|SIGSEGV in                  |GCJ: Using references drops
                   |GC_register_finalizer_inner |finalizers causing all apps
                   |()                          |to eventually crash  (
                   |                            |SIGSEGV in
                   |                            |GC_register_finalizer_inner
                   |                            |() )


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

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

------- Comment #16 from daney at gcc dot gnu dot org  2008-09-22 20:08 -------
This is biting me now.  Perhaps I may look at fixing it (or maybe not...).


-- 

daney at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daney at gcc dot gnu dot org


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

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

------- Comment #17 from daney at gcc dot gnu dot org  2008-09-22 23:56 -------
For me the testcase always gets a ConcurrentModificationException in w.clear()
very soon after starting.  This is on GCC trunk 140563 on x86_64-pc-linux-gnu.

If I synchronize(w) for accesses to w there is no
ConcurrentModificationException, but I have not seen it crash yet either.


-- 


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

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

------- Comment #18 from daney at gcc dot gnu dot org  2008-09-23 17:40 -------
Created an attachment (id=16396)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16396&action=view)
Possible work-around

This is a patch against 3.4.3 that we are seriously considering using
internally.  The theory is:  With code compiled from valid java source, it is
impossible to be GCable while holding a lock, so adding a finalizer is
redundant.

It is still not clear to me if the number of heavy_locks could grow without
bound while using the patch.  We are analyzing this now...


-- 


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

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

[Hans dot Boehm at hp dot com]

------- Comment #19 from Hans dot Boehm at hp dot com  2008-09-23 23:39 -------
I looked at this a bit, trying to remind myself of the logic.  I'm not
positive, but it looks plausible to me that doing without the finalizer might
work for most applications.  Historically, the finalizer was the only cleanup
mechanism for heavy locks.  But that turned out to be insuficient, and
maybe_remove_all_heavy was added.  It tries to occasionally remove long lists
of heavy locks, that were still observed to accumulate in some cases.  That's
probably usually enough to keep the list from growing without bounds.

I would however worry about an application that holds one or more locks
indefinitely.  At that point, the heavy_count for the corresponding hash entry
never drops to zero, and maybe_remove_all_heavy won't do its job for that
entry.  Thus I think the list of heavy locks for that entry will grow without
(reasonable) bounds.

As a result, I don't think this is curently a fully general fix, though it may
work for many applications.

I'm not positive, but it seems likely to me that one might be able to avoid
this "poisoning" effect of a single-in-use lock by adding in-use bits to heavy
locks, which are protected on the lock bit by the hash entry.  This may allow
unused entries to be cleaned up even if one or two heavy locks in the chain are
held.  That might turn this into a real fix, if it's not possible to fix this
elsewhere.  It might also simplify the code.


-- 


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

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

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