Beginning with the Sun Solaris™ SDK 1.3.0, there is only
one stack size parameter that can be configured for Java; this is the
-Xss. The -Xoss parameter was defined for SDK 1.2.2, but
it is ignored beginning with SDK 1.3.0. The HotSpot compiler does not have
a separate native and Java stack. (For details on the SDK 1.2.2 stack
parameters, refer to the end of this document.)
The stack is used to keep track of instance variables and references to
objects used by a thread. For each thread in the JVM™, there is a stack.
The size of the stack is determined by the -Xss value. There is a
default value.
Platform |
-Xss (thread stack size) |
Solaris |
Default: 512KB Minimum: 1KB Maximum: None specified
For SDK 1.3.1, this is the only stack parameter one may set. |
A stack overflow might be caused by Java calls or due to a native
library that is called from Java.
First, try to determine if the stack overflow is in native code or in
Java code. This is not always easy or possible. You must see the Java
stack trace associated with the stack overflow to be certain, and in some
cases you do not get this information. The information returned when the
stack overflow occurs is dependent upon the platform.
Second, you must determine if the stack overflow is caused by a
deeply-nested, but healthy loop, or by an infinite loop. If the cause is a
deeply-nested loop, increasing the size of the appropriate stack value
resolves the problem.
Diagnosing a stack overflow on Solaris
On Solaris, when a stack overflow occurs, the stack overflow might be
logged in an hs_err_pid*.log file for SDK 1.3.0 and 1.3.1.
In addition, something like the following is logged in the stdout
file of the JVM:
[5/13/03 11:20:34:171 EDT] 22b73c
WebGroup X Servlet Error: :
java.lang.StackOverflowError
<<no stack trace available>>
Note: For WebSphere® Application Server V4.0, the stdout file of
the administrative server Java process is the file tracefile.
Alternatively, the following might be logged in the stdout log
before an hs_err_pid*.log file creation trace event is logged.
*** "An irrecoverable stack overflow has occurred."
***
Something similar to the following is also logged in the stdout file, when
the JVM indicates what hs_err_pid*.log file was written.
An irrecoverable stack overflow has
occurred.
Unexpected Signal : 11 occurred at PC=0xfac29794
Function name=fillInStackTrace (compiled Java code)
Library=(N/A)
Some possible hs_err_pid*.log file entries that accompany a stack
overflow are:
- Then follows the HotSpot error:
"Unexpected Signal : 11 occurred at PC=0x955b0
Function name=(N/A)
Library=(N/A)
HotSpot Virtual Machine Error : 11
Error ID : 4F530E43505002BD 01"
- Unexpected Signal : 11 occurred at PC=0xfac29794
Function name=fillInStackTrace (compiled Java code)
Library=(N/A)
- An unexpected exception has been detected in native code outside the
JVM.
Unexpected Signal : 11 occurred at PC=0xff2708ec
Function name=memcpy
Library=/usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1
A stack overflow can occur in pstack or gdb output if the failing
thread has an inordinately large stack; for example, a large recursive
loop or infinite loop is identified by the same block of calls appearing
over and over again.
Determining the cause of a stack overflow
If the stack overflow might be because of a deeply-nested stack,
increase the size of the -Xoss. Certain types of applications,
such as graphics applications, require large amounts of stack space to
store temporary data. Be aware that an increase in the -Xoss
affects every thread of the JVM process. Each thread has this larger stack
size, so the amount of memory used by the JVM process increases.
The -Xoss parameter is a command-line argument for the Java
command line. To change this from the default size, specify the new value
in the Command line arguments of the Application Server (or administrative
server, if this is the JVM process that requires the larger stack).
If raising the stack size does not resolve the problem, it is possible
that the cause of the stack overflow is either a runaway thread or a
problem in the HotSpot compiler.
To check for a runaway thread, see MustGather: 100% CPU Usage on Solaris platforms.
Follow the instructions to take thread dumps and determine what method
calls are being made. Look for thread stacks that are large; that is, that
have deeply-nested calls. You can also use the output from a pstack call
to examine the JVM process and determine if there is a deeply-nested
call.
There have been HotSpot compiler problems that have caused stack
overflows to occur. Also, some problems have been caused by the Solaris 8
thread library. If you suspect this problem, do the following:
- Use the alternate thread library. See Changing to the alternate, one-to-one threading library
on Solaris 8 improves performance
- Migrate to the latest available SDK and test with -client HotSpot
compiler with -Xoss increased.
- Test use of -server and -client HotSpot compilers to
determine if this resolves the problem. See Setting up a HotSpot server or client mode on a Java 2
SDK
If the stack overflow is not fixed by adjusting the stack size, it is
possible that this is due to a Sun SDK bug. Check the SunBug Database at
http://java.sun.com to see if there is
one that matches your symptoms.
References for JVM parameters:
http://java.sun.com/j2se/1.3/docs/tooldocs/solaris/java.html
http://java.sun.com/docs/hotspot/VMOptions.html
Related Information
MustGather:
Out of Memory Errors on Solaris, Part 1
Disable
JIT Compiler in V5.0 |