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:

1. 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.

2. A DOS window should open up and remain open while lines about JBoss starting up print to the window.

3. 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."

4. From the DOS window, you need to use Ctrl+Break to get a stack trace.

5. 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:

SendSignal <JBOSS_PID>

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:

mstsc.exe /console

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

IBM JREs

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

export IBM_JAVACOREDIR="/var/log/"

I would recommend to put this line into run.conf also

export IBM_JAVADUMP_OUTOFMEMORY="true"

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:

export IBM_HEAPDUMPDIR="/var/log/"

export IBM_HEAP_DUMP="true"

export IBM_HEAPDUMP="true"

export IBM_HEAPDUMP_OUTOFMEMORY="true"

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

jmx-console.

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.

-

Related:

ThreadDump

Referenced by: