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

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

[Bug libgcj/12013] 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



------- Additional Comments From ddaney at avtrex dot com  2003-08-21 17:38 -------
Created an attachment (id=4633)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=4633&action=view)
Test case

[Bug libgcj/12013] 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



------- Additional Comments From ddaney at avtrex dot com  2003-08-21 17:39 -------
Created an attachment (id=4634)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=4634&action=view)
Proposed fix

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

[pinskia at gcc dot gnu dot org]

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


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2003-08-21 18:13:45
               date|                            |


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-08-21 18:13 -------
I can confirm this on the mainline (20030821).

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

[cvs-commit at gcc dot gnu dot org]

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



------- Additional Comments From cvs-commit at gcc dot gnu dot org  2003-08-21 22:08 -------
Subject: Bug 12013

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	tromey@gcc.gnu.org	2003-08-21 22:08:10

Modified files:
	libjava        : ChangeLog 
	libjava/java/lang/ref: Reference.java natReference.cc 

Log message:
	2003-08-21  David Daney  <ddaney@avtrex.com>
	
	Fix for PR libgcj/12013:
	* java/lang/ref/natReference.cc (finalize_referred_to_object):
	Check `cleared' field.
	* java/lang/ref/Reference.java (copy): Updated comments.
	(cleared): New field.
	(clear): Rewrote.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.2113&r2=1.2114
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/ref/Reference.java.diff?cvsroot=gcc&r1=1.4&r2=1.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/ref/natReference.cc.diff?cvsroot=gcc&r1=1.4&r2=1.5

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

[tromey at gcc dot gnu dot org]

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


tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


------- Additional Comments From tromey at gcc dot gnu dot org  2003-08-21 22:10 -------
Fix checked in.