How to generate and capture Java stack traces
Forced stack traces on UNIX/Linux:
Here are some methods for generating stack traces on UNIX.
First we give the basic, cut-and-paste method, followed by some work arounds for getting trace output into a file automatically.
Note the process ID number of the JBoss process (using top or a grep on ps -axw ) and send a quit signal to the process with the kill -QUIT or kill -3 command. example: kill -3 nnnn
This will generate a stack trace in the terminal window in which JBoss was originally started. You can redirect the trace output to a file, or copy and paste it from stdout into a file for closer examination.
If you have trouble redirecting the trace then modify the file $JBOSS_HOME/bin/run.sh by changing the line:
org.jboss.Main "$@" to read:
org.jboss.Main "$@" > jboss.trace
Save and restart JBoss normally. Now when you do the kill -3 or kill -QUIT you should see a stack trace in the file jboss.trace.
To get a forced stack trace from JBoss on Win32:
Make sure you are using java.exe to run JBoss, not javaw.exe. javaw.exe runs Java apps without a DOS window, whereas java.exe will open a DOS window to run them.
A DOS window should open up and remain open while lines about JBoss starting up print to the window.
Right-click on the DOS window's drag/location bar and select "Properties..." from the contextual menu. Click on the "Options" tab and select the "QuickEdit Mode" checkbox (this allows you to select text with the mouse). Click on the "Layout" tab. In the "Screen Buffer Size" selection box, set the height for 9999. Click "OK." A pop-up window appears asking you to choose how to apply the properties--make your choice and click "OK."
From the DOS window, you need to use Ctrl+Break to get a stack trace.
Use the mouse to select all the text in the stack trace output, then open Notepad or Wordpad and paste it in. Don't use "Ctrl-c" to copy the text from the DOS Window, as that will kill the app. and close the window. Just selecting the text will copy it.
Alternatively, a Ctrl+Break signal can be sent to the JBoss Java process using the SendSignal utility.
Download SendSignal, unzip it to a location, then run it from that location from the command line as follows:
If you get an "Access denied; retrying with increased privileges." error, note that the process must be your own, or you must have debug privileges.
If you use the remote connection on Windows, you need to start it as follows or you won't have sufficient rights to use the tool:
Stack traces will be sent to standard out, so you will want to redirect standard out to a file when starting JBoss. For example:
run.bat > console.log
On Linux, the IBM JDK and JREs will respond to a kill -QUIT by creating a javacore.txt file. By default it is written to the bin directory of JBoss, if this is impossible (e. g. because of file permissions) it is written to the /tmp directory.
If you would like some other location better, just set an environment variable
I would recommend to put this line into run.conf also
may be a good idea if You are analysing memory leaks.
In most cases of crashes it will be helpful, if You also get a heapdump, so put the following lines to run.conf if wanted:
For further information on how to obtain and examine a thread dump, the following Sun Technical Article entitled An Introduction to Java Stack Traces may be useful.
Getting a stack trace through the jmx-console
Starting with JBoss v3.2.8/4.0.2 and when running under a JDK5+ runtimeyou can get a stack trace for all running threads, using the
This function returns the information provided by Thread.getAllStackTraces(). This does not include the light weight thread id, which is important for troubleshooting hung and spinning processes; therefore, it is recommended to use the methods described above to obtain the stack trace if possible.
Class Histograms on Sun VMs
If you add the options -XX:+PrintClassHistogram you will see a list like that along with the thread dump (kill -3 / Ctrl+Break only)
num #instances #bytes class name -------------------------------------- 1: 20871 2471608 <no name> 2: 20871 1505392 <methodKlass> 3: 32456 1329000 <symbolKlass> 4: 1924 996632 <constantPoolKlass> 5: 1924 756552 <instanceKlassKlass> 6: 1685 602432 <constantPoolCacheKlass> 7: 2139 567128 [B 8: 5920 385648 [C 9: 2159 189992 java.lang.Class 10: 2614 164160 [S 11: 6193 148632 java.lang.String 12: 3107 140888 [[I 13: 1764 136056 [I 14: 1459 116720 java.lang.reflect.Method 15: 1186 95696 [Ljava.lang.Object; 16: 813 71344 [Ljava.util.HashMap$Entry;
This is really useful when you're having OutOfMemoryErrors at your application.