StackOverflow Exceptions can occur when a thread stack continues to grow in size until reaches to the maximum limit.
Symptom for getting the StackOverflow Errors
A stack overflow can result from:
--> A deeply nested application.
--> An infinite loop within an application.
--> A problem in just-in time (JIT) compiled code.
--> Applications requiring a larger stack size , especially one's relying on XML,GUI, or java2D classes.
--> Native method calls.
Stack overflow issues are frequently masked by Out of Memory exceptions.By resolving the memory constraints , the stack overflow can be resolved.
Cause
When a stack overflow occurs, the amount of stack space required by the program exceeds what is configured for the stack in the Java Virtual Machine(JVM) process , or the native stack size configured by the operating system.
Some applications require stacks that are larger than the default size .
for Example- a Graphical - intensive Java program can require a larger stack , which may requir an increase in the stack size to avoid StackOverflow.
Diagnosing the problem
Look for either Out of Memory messages or java.lang.StackOverflow in the server logs. the process may continue to run after either of these messages are seen.
If crash did occur ,a javacore should have generated on IBM SDK.You will either see the signal as SIGSEGV,SIGILL,SIGABRT, or SIGBUS, Usually the current thread will indicate the following state.
pending= java.lang.StackOverflowError
Resolution
1) Infinite Recursion- If an application is performing recursion , the maximum stack size can easily be reached and a stack Overflow exception is thrown. The thread stack has a limited size and eventually its space will run out as the thread stack grows without bounds.
Some traits of recursion:
--> Large thead stacks that appears to repeat.
--> An infinite loop that continuously spawns off threads.
--> Very large XML documents loaded into the document ObjectModel (DOM).
--> JSP or servlets calling itself (usually by executing forward or include to itself).
--> Repeated calls in active functions.
Increasing the thread stack size allows for larger thread stacks. However if the recursion continues to trigger a stack overflow , the next step is to identify what code is causing the recursion from javacores, thread dumps, or even system core files.
A Thread stack that indicates it's too large to display can be an indicator of stack overflow. This is especially true if the stack appears to repeat such as recusive method calls.
JIT/HotSpot Compiled Code
The JIT/HotSpot compiler (JIT) is designed to speed up the JVM execution times by compiling method calls. This can speed up execution time, but as more aggressive optimizations are used , this can inadvertently cause recursion , resulting in stack overflow or crash. The documents linked below explain how to debug JIT and HotSpot Compiler Issues:
Deplated Native Stack
It is almost guaranteed that a crash will occur if the native stack runs out of space. System cores can be used to identify long and possible recursively looping native Thread stacks.
To resolve , increase the native stack size by adjusting the operating system limit for stack Size to accommodate the recursive native calls however, Identify the recursive native calls will help determine the root cause of the stack overflow.
Adjusting the Stack Sizes (XSS and Xmso) options
If this does not work, you can adjust the stack sizes. Doubling the stack size is suggested as a firsted step however every Thread that the JVM creates will consume memory. Be careful to not exhaust your physical and heap memory resources.
For every java Thread , there are two stacks that are utilized. One is for Java code for method calls, and the other is for native C Lang Code but on Solaries and HP-UX only the native stack is utilized. these are adjustable and can be raised to provided more room on the stacks to prevent an overflow.
Maximum Thread Stack Size(-Xss)
This parameter controls the stack size of Java method calls that are non native to track the state of variables. If you find looping code or large stacks that are all calling Java methods and do not make native calls, try raising the stack size by using the generic JVM argument below:
-Xss<size>
where size has the format ,nn[k|m|g|M|G] , for example: -Xss512K
On Solaries and HP-UX systems which use the HotSpot JVM , there is no distinction between native and thread stack sizes. this is ths only configurable value for all stack sizes however on HP-UX systems , there is another argument used to control stack size of the UX systems,there is another argument used to control stack size of the main method.
-XX:MainThreadStackSize=<size>
while the -Xss controls the stack size of all threads in native memory, -XX: MainThreadStackSize controls the size of the main thread. The main thread's native size will be set to whichever value is higher.
Initial Thread Stack Size (Xiss)
This is for distributed platforms (AIX,LINUX,Windows)
Adjust the initial thread stack size that the JVM will start with. The default for all distributed platforms is 2KB. In most cases, you will need to change this option
-Xiss<size>
Where <size> has the format , nn[k|m|g|K|M|G] , for example Xiss2k
Initial Native Stack Size(-Xmso)
This is only for distriuted platforms(AIX,Linux,Windows)
This parameter controls the initial stack size of native (operating system) threads. Java code uses this to process calls made into native libraries,such as JIT or JNI calls. If there is an abundance of calls made on the native stack , adjust the native stack size using this generic JVM argument
-Xmso<size>
where <size> has the format nn[k|m|g|K|M|G] s -Xmso512k
Note: The maximum stack size for the operating system is controlled by ulimit -s on UNIX and LINUX
Default values
Initial Thread Stack Size Max Thread stack Size Native Stack Size
AIX /Linux 2KB 256KB (in 32bit) 256KB
512KB (in 64bit)
Windows 2KB 256KB(in 32bit) 32KB(in 32bit)
512KB(in 64bit) 256KB(in 64 bit)
Server logs
These logs my contain references to StackOverflow ,alongside other messages. Thread stacks may accompany these messages , indicating if htere is a recursive call.
In SystemOut.log
the following text will be recorded
[3/14/15 2:20:10: 783 CST] 314 15926 BaseMap CWOBJ0006W: An exceptio occured:
com.ibm.websphere .objectgrid.ObjectGridRuntimeException:
java.lang.StackOverflowError
In SystemErr.log
[3/14/15 3:14:15:865 PST] 314 15926 SystemErr R caused by: java.lang.StackOverflowError
at java.util.Hashtable.get(Hashtable.java:462)
at com.ibm.ws.webcontainer.srt.SRTServletRequest.getParameter(SRTServletRequest.java:1257)
at
psdi.webclient.system.session.WebClientSession.applySkin(WebClientSession.java:295)
at
psdi.webclient.system.controller.AppInstance.render(AppInstance.java:1177)
at
psdi.webclient.system.controller.AppInstance.render(AppInstance.java:1213)
In Thread Dump(java core)
In javacore , look for "StackOverflow Error" in the thread name entry:
3XMTHREADINFO " ORB.thread.pol : 19" (TID : 10167F78, sys_thread_t: E072BCEO, state: R, native ID : E06BEBA0) PRIO=5: PENDING=JAVA.LANG.sTACKoVERFLOWeRROR
In System Dump
Look for this message near the end of a very large stack. This we has 1700 recursively called entries.
Java stack frames dump is too long:
<analyzerror>
Symptom for getting the StackOverflow Errors
A stack overflow can result from:
--> A deeply nested application.
--> An infinite loop within an application.
--> A problem in just-in time (JIT) compiled code.
--> Applications requiring a larger stack size , especially one's relying on XML,GUI, or java2D classes.
--> Native method calls.
Stack overflow issues are frequently masked by Out of Memory exceptions.By resolving the memory constraints , the stack overflow can be resolved.
Cause
When a stack overflow occurs, the amount of stack space required by the program exceeds what is configured for the stack in the Java Virtual Machine(JVM) process , or the native stack size configured by the operating system.
Some applications require stacks that are larger than the default size .
for Example- a Graphical - intensive Java program can require a larger stack , which may requir an increase in the stack size to avoid StackOverflow.
Diagnosing the problem
Look for either Out of Memory messages or java.lang.StackOverflow in the server logs. the process may continue to run after either of these messages are seen.
If crash did occur ,a javacore should have generated on IBM SDK.You will either see the signal as SIGSEGV,SIGILL,SIGABRT, or SIGBUS, Usually the current thread will indicate the following state.
pending= java.lang.StackOverflowError
Resolution
1) Infinite Recursion- If an application is performing recursion , the maximum stack size can easily be reached and a stack Overflow exception is thrown. The thread stack has a limited size and eventually its space will run out as the thread stack grows without bounds.
Some traits of recursion:
--> Large thead stacks that appears to repeat.
--> An infinite loop that continuously spawns off threads.
--> Very large XML documents loaded into the document ObjectModel (DOM).
--> JSP or servlets calling itself (usually by executing forward or include to itself).
--> Repeated calls in active functions.
Increasing the thread stack size allows for larger thread stacks. However if the recursion continues to trigger a stack overflow , the next step is to identify what code is causing the recursion from javacores, thread dumps, or even system core files.
A Thread stack that indicates it's too large to display can be an indicator of stack overflow. This is especially true if the stack appears to repeat such as recusive method calls.
JIT/HotSpot Compiled Code
The JIT/HotSpot compiler (JIT) is designed to speed up the JVM execution times by compiling method calls. This can speed up execution time, but as more aggressive optimizations are used , this can inadvertently cause recursion , resulting in stack overflow or crash. The documents linked below explain how to debug JIT and HotSpot Compiler Issues:
Deplated Native Stack
It is almost guaranteed that a crash will occur if the native stack runs out of space. System cores can be used to identify long and possible recursively looping native Thread stacks.
To resolve , increase the native stack size by adjusting the operating system limit for stack Size to accommodate the recursive native calls however, Identify the recursive native calls will help determine the root cause of the stack overflow.
Adjusting the Stack Sizes (XSS and Xmso) options
If this does not work, you can adjust the stack sizes. Doubling the stack size is suggested as a firsted step however every Thread that the JVM creates will consume memory. Be careful to not exhaust your physical and heap memory resources.
For every java Thread , there are two stacks that are utilized. One is for Java code for method calls, and the other is for native C Lang Code but on Solaries and HP-UX only the native stack is utilized. these are adjustable and can be raised to provided more room on the stacks to prevent an overflow.
Maximum Thread Stack Size(-Xss)
This parameter controls the stack size of Java method calls that are non native to track the state of variables. If you find looping code or large stacks that are all calling Java methods and do not make native calls, try raising the stack size by using the generic JVM argument below:
-Xss<size>
where size has the format ,nn[k|m|g|M|G] , for example: -Xss512K
On Solaries and HP-UX systems which use the HotSpot JVM , there is no distinction between native and thread stack sizes. this is ths only configurable value for all stack sizes however on HP-UX systems , there is another argument used to control stack size of the UX systems,there is another argument used to control stack size of the main method.
-XX:MainThreadStackSize=<size>
while the -Xss controls the stack size of all threads in native memory, -XX: MainThreadStackSize controls the size of the main thread. The main thread's native size will be set to whichever value is higher.
Initial Thread Stack Size (Xiss)
This is for distributed platforms (AIX,LINUX,Windows)
Adjust the initial thread stack size that the JVM will start with. The default for all distributed platforms is 2KB. In most cases, you will need to change this option
-Xiss<size>
Where <size> has the format , nn[k|m|g|K|M|G] , for example Xiss2k
Initial Native Stack Size(-Xmso)
This is only for distriuted platforms(AIX,Linux,Windows)
This parameter controls the initial stack size of native (operating system) threads. Java code uses this to process calls made into native libraries,such as JIT or JNI calls. If there is an abundance of calls made on the native stack , adjust the native stack size using this generic JVM argument
-Xmso<size>
where <size> has the format nn[k|m|g|K|M|G] s -Xmso512k
Note: The maximum stack size for the operating system is controlled by ulimit -s on UNIX and LINUX
Default values
Initial Thread Stack Size Max Thread stack Size Native Stack Size
AIX /Linux 2KB 256KB (in 32bit) 256KB
512KB (in 64bit)
Windows 2KB 256KB(in 32bit) 32KB(in 32bit)
512KB(in 64bit) 256KB(in 64 bit)
Server logs
These logs my contain references to StackOverflow ,alongside other messages. Thread stacks may accompany these messages , indicating if htere is a recursive call.
In SystemOut.log
the following text will be recorded
[3/14/15 2:20:10: 783 CST] 314 15926 BaseMap CWOBJ0006W: An exceptio occured:
com.ibm.websphere .objectgrid.ObjectGridRuntimeException:
java.lang.StackOverflowError
In SystemErr.log
[3/14/15 3:14:15:865 PST] 314 15926 SystemErr R caused by: java.lang.StackOverflowError
at java.util.Hashtable.get(Hashtable.java:462)
at com.ibm.ws.webcontainer.srt.SRTServletRequest.getParameter(SRTServletRequest.java:1257)
at
psdi.webclient.system.session.WebClientSession.applySkin(WebClientSession.java:295)
at
psdi.webclient.system.controller.AppInstance.render(AppInstance.java:1177)
at
psdi.webclient.system.controller.AppInstance.render(AppInstance.java:1213)
In Thread Dump(java core)
In javacore , look for "StackOverflow Error" in the thread name entry:
3XMTHREADINFO " ORB.thread.pol : 19" (TID : 10167F78, sys_thread_t: E072BCEO, state: R, native ID : E06BEBA0) PRIO=5: PENDING=JAVA.LANG.sTACKoVERFLOWeRROR
In System Dump
Look for this message near the end of a very large stack. This we has 1700 recursively called entries.
Java stack frames dump is too long:
<analyzerror>
