IncompatibleClassChangeError. Caused by garbage collection?

Question

The problem occurs on JDK 1.3.1-b24 compiled in JBuilder Windows and
running on Sun Solaris with identical JDK version.
The application is a relatively complex RMI server.
An error recovery function in the server runs in a Thread every two
minutes. Most of the time it has nothing to do and ends without
incident.
Occasionally conditions require recovery that may not be successful
for many attempts.
Part of the recovery is a simple debug display of parameters involved
in the recovery. There will be multiple displays during a single
recovery cycle.
In a recent example of problem, the recovery executed every two
minutes for over two hours with the debug display working
successfully.
Suddenly one display works successfully and 5 milliseconds later the
same display fails with a IncompatibleClassChangeError.
The last part of the stack trace is:
java.lang.IncompatibleClassChangeError
     at [class name].toString([class name].java:74)
     at java.lang.String.valueOf(String.java:1947)
     at java.lang.StringBuffer.append(StringBuffer.java:370)
     at java.util.AbstractMap.toString(AbstractMap.java:567)
     at java.lang.String.valueOf(String.java:1947)
line 74 of class is
public String toString()
return _responses.toString();
where _responses is an ArrayList that has been stored on Map that
contains the parameters that is being display as part of the debug
information.
Once the failure occurs, it will always occur until the JVM is
restarted. This suggests to me that something in the JVM, maybe garbage collection, has either corrupted the in-memory copy of the class or some internal table used by the JVM has become corrupted.
Anybody else have ideas?

Answer 1

java.lang.IncompatibleClassChangeError
     at [class name].toString([class name].java:74)
     at java.lang.String.valueOf(String.java:1947)
at
java.lang.StringBuffer.append(StringBuffer.java:370)
at
java.util.AbstractMap.toString(AbstractMap.java:567)
     at java.lang.String.valueOf(String.java:1947)
Problem: The IncompatiableClassChangeError is a Symbolic resolution problem. In lamen's terms a package,class,method,or a variable name is corrupted.
Possible problem location: Are you using a Custom ClassLoader? Do you Load and compile on the fly?
where _responses is an ArrayList that has been stored
on Map that
I would look hard at the following methods in your MAP Interface:
public void clear();
public Object put(Object key,Object value);
public void putAll(Map t);
public Object remove(Object key);Is it possible that your MAP interface is corrupting your ArrayList using one of the above methods? Then, when you are building the strings using the AbstractMap's.toString() method, you are getting the IncompatiableClassChangeError?
This is word for word listing of the MAP Interface...V1.41.
Some map implementations have restrictions on the keys and values they may contain. For example, some implementations prohibit null keys and values, and some have restrictions on the types of their keys.
This puzzles me
Attempting to insert an ineligible key or value throws an unchecked exception, typically NullPointerException or ClassCastException.
What's this, they state above that you should get a unchecked Exception, but the first sentence below makes me assume they are pulling a query on an ineligible key or value???
Attempting to query the presence of an ineligible key or value may throw an exception, or it may simply return false; some implementations will exhibit the former behavior and some will exhibit the latter.
Oh,OK. They are basically saying it totally depends on how you implement this Interface <grin>
More generally, attempting an operation on an ineligible key or value whose completion would not result in the insertion of an ineligible element into the map may throw an exception or it may succeed, at the option of the implementation.
The "optional" they are talking about are the methods that I listed above.
Such exceptions are marked as "optional" in the specification for this interface.
Well you asked for ideas, so there's a brain fart for you?
...Hope this helps