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

Fri Aug 15 01:18:00 GMT 2003

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