StackOverflowError when serializing an object in Java

Question

I am writing an application in Java using Swing. I am trying to implement functionality to save and load simulation states for at simulation i am running. The entire simulat

Answer 1

You've got some deeply nested ArrayLists.

I think maybe it's just going depth first, and that means it's going for the bottom Sensor, which is too deep.

Maybe you could create a custom structure with Sensors starting with the bottom Sensor?

Or maybe you'll have to provide your own serialisation to handle it? http://java.sun.com/developer/technicalArticles/Programming/serialization/

Answer 2

Run java with bigger stacks

Answer 3

And after you done all that just use XStream instead if you only want to save to a file.

Answer 4

You should consider reimplementing the writeObject / readObject methods of your Simulation class in order to serialize only the relevant data (and not the entire contained object structure by default) or tagging transient your not to be serialized objects. You can also use the Externalizable interface if needed.

BTW, you may want to read this interesting article to begin with.

Answer 5

Interesting post from Chen:

When debugging a stack overflow, you want to focus on the repeating recursive part

In your case:

        at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
        at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
        at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
        at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
        at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
        at java.util.ArrayList.writeObject(ArrayList.java:570)
        at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
        at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461)

If you go hunting through your defect tracking database trying to see whether this is a known issue or not, a search for the top functions on the stack is unlikely to find anything interesting. That's because stack overflows tend to happen at a random point in the recursion; each stack overflow looks superficially different from every other one even if they are the same stack overflow.

Once you get past the initial turmoil, the stack trace settles down into a nice repeating pattern consisting of the same x functions over and over again.
Identifying the start of the repeating pattern isn't important, because the starting point will be different for each crash, in the same way that the precise note which exceeds your singing range varies from crash to crash.

Once you've identified the repeating part, pick a function from it that is somewhat unusual and search for it in your defect database.

For example, an default ArrayList serialization.

Here your GrahPanel refers a Simulation which refers to Graph, with potentially long ArrayList of Sensor and Edge...

Java serialization keeps a record of every object written to a stream. If the same object is encountered a second time, only a reference to it is written to the stream, and not a second copy of the object; so circular references aren't the problem here.

But serialization is vulnerable to stack overflow for certain kinds of structures; for example, a long linked list with no special writeObject() methods will be serialized by recursively writing each link. If you've got a 100,000 links, you're going to try to use 100,000 stack frames, and quite likely fail with a StackOverflowError.

It's possible to define a writeObject() method for such a list class that, when the first link is serialized, simply walks the list and serializes each link iteratively; this will prevent the default recursive mechanism from being used.

Answer 6

I had a similar problem. After much hunting, I found a fork of Kryo designed to handle deeply nested objects. Via https://github.com/EsotericSoftware/kryo/issues/103 , clone and mvn clean install https://github.com/romix/kryo/tree/kryo-2.23-continuations . It's currently com.esotericsoftware.kryo:kryo:2.23-SNAPSHOT.