[Bug libgcj/12013] New: Calling Reference.clear() can cause runtime to crash.

[ddaney at avtrex dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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

           Summary: Calling Reference.clear() can cause runtime to crash.
           Product: gcc
           Version: 3.3.1
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: libgcj
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ddaney at avtrex dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu

Finally found it!  The attached test program exercises a bug in libgcj's
lava.lang.ref.Reference handling code (from gcc 3.3.1).  It crashes on both my
i686-pc-linux-gnu and mipsel-linux platforms

If Reference.clear() is called and then the Reference is finalized
before its referent, a dangling pointer is created in the object_list
structure in natReference.cc.  This happens because the 'copy' field
of the Reference is cleared and that is what is used to find the slot
in the object_list table.

When more objects are allocated, this dangling pointer now can point
to an object of some other type.

Now when the original referent is finalized, all of the References to
it are enqueued, but since some of the pointers to these References
are invalid, the called to enqueue() (via a now invalid vtable) sends
us off into some place bad.

There seem to be two ways to fix the problem.

1) Never clear the 'copy' field in the Reference and add a boolean
    field to Reference that is set to detect the cleared condition.
    Doing this we will always be able to find the Reference in the
    object_list.

2) If 'copy' is null, then scan the entire object_list tree looking
   for the entry that points to the Reference and remove it.


I have attached a patch that does #1.

Question: Does adding a field to Reference cause binary compatibility
problems between different versions of shared libgcj?

I don't think so because all fields are package private.

Option 2 preserves the size and layout of Reference, but would be
slower and require bigger changes to natReference.cc

My patch includes changes from Tom Tromey's patch of yesterday.