JDK-6489672 : regression: Deserialize Object causes StackOverflowError Exception
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io:serialization
  • Affected Version: 5.0u9
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-11-03
  • Updated: 2010-09-29
  • Resolved: 2006-12-07
Related Reports
Duplicate :  
JDK-4152790 - StackOverFlowError serializing/deserializing a large graph of objects.
Description
This program works OK on jdk5.0u7. 
But it will failed on jdk5.0u9. 
It will run twice to deserialize Object from files.
The first function call to deserialize Object will be ok.
But the second function call will failed with Stackflow Exception
I uploaded a sample java src file for evaluation as well as the sample seralization file that will be loaded by the sample java program.
Comments
WORK AROUND Increase the VM's stack size: see the -Xss VM option.
08-11-2006
EVALUATION The attached serialization stream (file "store.txt") contains a deeply nested graph of serialized objects-- its maximum depth is 687, with the deep containment mostly caused by instances of com.sun.org.apache.xerces.internal.dom.ElementNSImpl-- which is generally problematic for Java object serialization. See 4152790, as well as page 220 of Josh Bloch's book "Effective Java", which cautions against deep containment in serialized form design. Regarding why a StackOverflowError occurs using this particular stream with 5.0u8 (on Windows XP) but not 5.0u7, I can't say for certain. I can't reproduce the attached test case's failure with 5.0u8 on Solaris/SPARC (with either -client or -server) with the default stack size. There was no significant change in ObjectInputStream's use of stack space in between 5.0u7 and 5.0u8 (e.g., no new method invocations), although there were a couple of local variables added to one of the methods involved. But the precise amount of stack space actually consumed by an operation surely varies slightly due to many factors stemming from the underlying platform, the VM version, the core libraries version, etc. Because of these inherent vagaries, it's difficult to characterize the reported change in behavior as a regression. The attached test case is clearly very "close to the edge" in stack space consumption with the client VM's default stack size. If I lower the stack size to 500KB with -client (from the default 512KB on Solaris/SPARC), I do reproduce the failure on Solaris/SPARC with 5.0u8, but not 5.0u7. I can reproduce the failure on 5.0u7 too with the stack size set down to 480KB, demonstrating a slight difference in sensitivity between the releases. Increasing the VM's per-thread stack size should work around this failure: see the -Xss VM option.
08-11-2006