Help me isolate bug in natReference.cc or related code...

[David Daney <ddaney at avtrex dot com>]

Let me appologize in advance for not having enough information to really 
 find the problem I am having, but I thought someone might have some 
ideas for me.

I am running a java program compiled with gcc-3.3.1's gcj with 
mipsisa32el-linux as the target.  I have patched gcj to use SIGSEGV to 
handle NPEs (this is kind of a red hearing because the same problem 
exists without the patch).  We are using a shared libgcj.so.4.0.0

We are getting a crash in the garbage collection thread.

Perodically the garbage collector enters the function 
finalize_referred_to_object(jobject) where it enters this loop:
.
.
.
while (head && head->weight <= w)
{
  java::lang::ref::Reference *ref
    = reinterpret_cast<java::lang::ref::Reference *> (head->reference);
   // If the copy is already NULL then the user must have
   // called Reference.clear().
   if (ref->copy != NULL)
      ref->enqueue ();

   object_list *next = head->next;
   _Jv_Free (head);
   head = next;
}
.
.
.

Most of the time head->reference points to either a 
java.lang.ref.WeakReference or java.lang.ref.SoftReference which is what 
one would expect.

Now for the buggy behavior.  Occasionally the object pointed to by 
head->reference is an object of a different type (java.util.ArrayList is 
a popular one, but not always)  This causes a crash when ref->enqueue() 
is called because the vtable of the unexpected object sends it off to 
never never land.


Has anyone seen this before?  Is it a known bug with a fix I could obtain?

If neither of these, any suggestions on how to find the real cause?

Thanks in advance.
David Daney