You can configure two stack size parameters for Java code:
- The -Xss parameter for the native stack, used by
Java code to process calls made into native libraries.
- The -Xoss parameter for the Java stack, used for
Java method calls to track the state of variables.
For each thread in the Java Message Service (JMS), there is a Java
stack and a native stack. Default values include:
Platform |
-Xoss (Java stack size) |
-Xss (native stack size) |
AIX |
Default: 400 KB Minimum: 100 KB Maximum: None
specified |
Default: 512 KB Minimum: 96 KB Maximum: None
specified |
Ask the following questions:
- Does a stack overflow exist in native code or in Java
code?
- View the Java stack trace associated with the stack overflow, if this
information is available.
- Be aware that the information that is returned when the stack overflow
occurs is dependent upon the platform.
- Realize that in many cases it is not possible to get complete or
usable information.
- Does there appear to be an infinite loop?
- Verify if the pattern of calls repeats. Is a recursive loop of calls
occurring?
- View the source code or use a debugger to determine if a deep stack is
normal, even with some repeat calls in the stack trace.
- If there does not appear to be a loop, increase either the Java stack
or the native stack to resolve the problem.
Diagnosing a stack overflow on AIX
The symptoms of a stack overflow include:
- A java.lang.StackOverflowError exception in the system out
or system error file. This error is not a terminating exception. The Java
process might continue to run.
- Often, however, the java.lang.StackOverflowError does
cause a JVM crash, producing a javacore*.txt file. The javacore file lists
the signal throw, usually: SIGSEGV, SIGILL, SIGABRT, or SIGBUS.
The signal varies, depending on what memory is overwritten by the stack
overflow:
- The current thread often indicates
pending=java.lang.StackOverflowError.
- These signals can occur from failures other than stack
overflow.
- If a JVM crashes and the core is formatted using the IBM
jcore utility, a java.lang.StackOverflowError can be identified from the
jcore output. Usually jcore plainly identifies the possible existence of a
stack overflow in the Current thread details of the failing thread.
For example, this is output from a native
stack overflow.
*** CHECK *** possible thread stack overflow (FFFFED1C) by r15
(00000000)
*** ERROR *** stack trace possibly aborted (000018A0 left
untraced)
Here is output from another stack overflow:
*** ERROR *** definite thread stack overflow (31BA3FE4 <
31BA4000)
- Long call stacks in the javacore and/or jcore output do
not always mean a stack overflow has occurred. Long call stacks often
occur with a terminating exception or when a thread dump is
requested.
- When a stack overflow occurs, the javacore file might
identify a stack overflow in a thread.
Example:
"Worker#12" (TID:0x82925a78, sys_thread_t:0x322bdb18, state:R, native
ID:0x2022) prio=5
----- Native Stack -----
unable to backtrace through native code - iar 0x7 not in text area
(sp is 0x32ee0e00)
Determining if a stack overflow is Java or native
A stack overflow in the Java heap is evident from the javacore file by
the lack of a native stack in the Current Thread Details, and by the
pending=java.lang.StackOverflowError in the thread information of the
Current Thread.
Example:
1XMCURTHDINFO Current Thread Details
NULL ----------------------
3XMTHREADINFO "Servlet.Engine.Transports : 2553"
(TID:0x3045DAE0, sys_thread_t:0x7ED8EAA8, state:R, native ID:0x5885)
prio=5: pending=java.lang.StackOverflowError
4XESTACKTRACE at
com.ibm.ejs.j2c.poolmanager.SharedPool.getSharedConnection(SharedPool.java:198)
4XESTACKTRACE at
com.ibm.ejs.j2c.poolmanager.PoolManager.reserve(PoolManager.java(Compiled
Code))
4XESTACKTRACE at
com.ibm.ejs.j2c.ConnectionManager.allocateMCWrapper(ConnectionManager.java(Compiled
Code))
A native stack overflow shows calls in native libraries in the Java
stack trace of the jcore, like this:
*** ERROR *** SIGABRT raised by software in libjvm.a
(ip)=D2AF5D44 at libjvm.a + 087D44
unwinding (old_sp=33638BD8 old_ip=D2AF5D44)
(ip)=D2AF18D8 at libjvm.a + 0838D8
unwinding (old_sp=33638C38 old_ip=D2AF18D8)
(ip)=D2B8F134 at libhpi.a + 007134
unwinding (old_sp=33638C78 old_ip=D2B8F134)
(ip)=D2B8F1B0 at libhpi.a + 0071B0
unwinding (old_sp=33638CB8 old_ip=D2B8F1B0)
(ip)=D2B8F998 at libhpi.a + 007998
unwinding (old_sp=33638D08 old_ip=D2B8F998)
What to do with a Java stack or native overflow
Examine the stack associated with the java.lang.StackOverflowError and
make sure that there is not a bug in an application that is causing the
problem.
If the cause is not an application error, try incrementing the stack
size:
- Increase the size of the appropriate stack incrementally (-Xoss for
the java stack, -Xss for the native stack).
- Test.
- Repeat these actions until the error is eliminated. To change this
stack value from the default size, specify a new value in the command line
arguments of the WebSphere® Application Server.
Notes:
- The suggested starting point is double the default stack size.
- Remember that increasing the stack size increases the memory required
for each thread.
- The appropriate value can change when the Java 2 SDK is upgraded.
- Increasing the stack is not the solution if OutOfMemoryError
exceptions occur with an increased stack size.
- If increasing the stack sizes does not work, the following options
might still resolve the problem:
|