StackOverflowError on Solaris but not on Linux/Windows

Question

I have a Java application that parses a large xml schema (.xsd) using Xerces that runs fine on Linux and Windows but gives a StackOverflowError on Solaris, with exactly the same inputs and configuration. I know that Xerces uses recursion to validate xml schemas but since it didn't give any problems on Windows and Linux I was pretty confident that it run everywhere.

Why does this happen? Is there a workaround?

Answer 1

According to this page, the default stack size depends on the OS.

Sparc: 512

Solaris x86: 320 (was 256 prior in 5.0 and earlier) (update: According to this page, the size of the main thread stack comes from the ulimit. The main thread stack is artificially reduced by the vm to the -Xss value)

Sparc 64 bit: 1024

Linux amd64: 1024 (was 0 in 5.0 and earlier) (update: The default size comes from ulimit, but I can be reduced with -Xss)

Windows: 256 (also here)

You can change the default setting with the -Xss flag. For example:

java ... -Xss1024k ... <classname>

would set the default stack size to 1Mb.

Answer 2

Note that Hotspot VM parameter defaults may be different for different architectures. I would determine the defaults under Windows/Linux, and try setting those for Solaris.

For example:

-XX:ThreadStackSize=512 - Thread Stack Size (in Kbytes). (0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.]

(I'm not suggesting this particular parameter is the problem. Merely highlighting its differences under different OSes)

Answer 3

This is likely because the default maximum stack size differs between platforms.

You can specify the stack size using the -Xss command line to the JVM, e.g.

java -Xss256k

For a 256k stack. This is allocated on a per-thread basis.

Answer 4

Quote from javadoc:

StackOverflowError:
Thrown when a stack overflow occurs because an application recurses too deeply.

How big a stack is, created for each method, is implementation dependent. That's the reason.