Have Geek Brain

StackOverflowError on Solaris but not Linux / Windows

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

Why is this happening? Is there a workaround?

+1


a source to share


4 answers


As per this page , the default stack size is OS dependent.

Sparc: 512

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

Sparc 64 bit: 1024

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



Windows: 256 (also here )

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

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

set the default stack size to 1 MB.

+5


a source


Please note that the default Hotspot VM settings may be different for different architectures. I would define defaults on Windows / Linux and try to set them for Solaris.

For instance:



-XX: ThreadStackSize = 512 - The size of the stack stack (in kilobytes). (0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 earlier in 5.0 and earlier) Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier) all other 0.]

(I am not suggesting that this particular setting be an issue. Just highlighting its differences across OSes)

+1


a source


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

You can specify the stack size using the -Xss command line in the JVM like

java -Xss256k

For a 256k stack. This is distributed to each thread.

+1


a source


Quoting from the javadoc:

StackOverflowError :
Thrown when a stack overflow occurs because the application is recalculating too much.

How big the stack is created for each method is implementation dependent . This is the reason.

-1


a source






More articles:


All Articles