ansaurus

Question

StackOverflowError when serializing an object in Java

Answer 1

+1 A:

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/

Douglas Leeder 2009-01-13 13:14:48

Answer 2

A:

You should create a container class for the objects you want to store. I would not store the complete this object with all the logic inside.

Store first field by field to find the element which is to big to store it that way. Than put a breakpoint in the methode and take a look at the field element. Does the element contains links which link to each other?

Markus Lausberg 2009-01-13 13:18:44

Answer 3

+2 A:

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.

WiseTechi 2009-01-13 13:27:16

Answer 4

A:

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

willcodejavaforfood 2009-01-13 13:46:49

Answer 5

+1 A:

Run java with bigger stacks

2009-01-13 13:46:58

Answer 6

+3 A:

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.

VonC 2009-01-13 13:53:45

ansaurus

tags:

views:

answers:

StackOverflowError when serializing an object in Java

related questions