This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Help me isolate bug in natReference.cc or related code...
- From: Tom Tromey <tromey at redhat dot com>
- To: David Daney <ddaney at avtrex dot com>
- Cc: java at gcc dot gnu dot org
- Date: 15 Aug 2003 13:46:38 -0600
- Subject: Re: Help me isolate bug in natReference.cc or related code...
- References: <3F3C34FA.2090001@avtrex.com>
- Reply-to: tromey at redhat dot com
>>>>> "David" == David Daney <ddaney@avtrex.com> writes:
David> Now for the buggy behavior. Occasionally the object pointed to by
David> head-> reference is an object of a different type (java.util.ArrayList
David> is a popular one, but not always) This causes a crash when
David> ref-> enqueue() is called because the vtable of the unexpected object
David> sends it off to never never land.
David> Has anyone seen this before?
Not me.
David> If neither of these, any suggestions on how to find the real cause?
If I were debugging this, I would put a watchpoint on the memory
location that has the invalid data. Then you can see what is writing
to this memory. If it doesn't look like the location of
head->reference is being written to, then put a watchpoint on the
vtable itself. (i.e., one theory is that the tables in natReference
are being trashed somehow, another theory is that the object is
collected and the memory reused for something else, meaning that for
some reason the reference code didn't clean up its table).
This will be pretty painful unless your target has hardware
watchpoints.
Tom