Re: Why does this program cause an NPE in LibgcjInternalFinalizerThread??

[Jeff Sturm <jsturm at one-point dot com>]

On Tue, 19 Aug 2003, David Daney wrote:
> The object_list.reference is pointing to either a WeakReference or a
> SoftReference.  At some as yet unknown point it points something other
> than one of these, causing a crash usually when ref->enqueue() is called
> because the vtable of the object is not a Reference vtable.

I can see this on x86 with your first test program.  The crash occurs
on line 253:

250               // If the copy is already NULL then the user must have
251               // called Reference.clear().
252               if (ref->copy != NULL)
253                 ref->enqueue ();

> My current thought is that the WeakReference is being GCed
> and its space is then given to a new object (probably a String with this
> test program) and now the object_list.reference pointer is pointing to
> the new object rather than the WeakReference.

Sounds plausible.  gdb doesn't let me print the "ref" variable
directly, however the only register I have that looks like a heap pointer
is $eax:

(gdb) x $eax
0x8180c78:      0x407f1568
(gdb) x 0x407f1568
0x407f1568 <_ZTVN4java4lang6StringE+8>: 0x407f15a0

which clearly has a java.lang.String vtable.

What I don't understand is why finalize_reference doesn't prevent this
from happening.  The ref cannot be GC'ed before finalize_reference is
called, and after it is called it is explicitly removed from the hash
table.

Jeff