One of the useful troubleshooting utilities in J2SETM 5.0 is jstack. It prints the stack traces of all java threads for a given process or core dump. The -m option will print a mixed-mode stack so that you can see native frames in addition to the java frames. jstack was originally created for troubleshooting problems involving hangs and crashes but developers have found it a useful utility to look at running applications too.

jstack isn't the only way to obtain a thread dump of a running application. Developers have long been accustomed to using Ctrl-\\ (or Ctrl-Break if you are on Windows) to get a thread dump of an application that is running interactively. An alternative to the key sequence on Solaris (or Linux) is to send a QUIT signal to the target process. In that case the target processs prints a thread dump to its standard output (which can be pain if you don't know where the log file is).

If you are lucky to be on Solaris 10, then yet another way to obtain a stack trace is using the the pstack utility. This has been updated in Solaris 10 so that it prints java method names for interpreted, compiled and inlined java methods. pstack prints a mixed-mode stack and the output is similar to jstack -m.

Mustang (Java SE 6.0) brings more improvements. For starters the default mode for jstack is to work a bit like a remote Ctrl-\\. This means that the output of the thread dump has changed a bit but there is more information on deadlocks and JNI Global References in additional to the thread stacks. If the VM is hung then a thread dump can still be forced using the -F option.

The second improvement is that jstack is included on Windows. It doesn't have all the features yet of the jstack utility on Solaris but it does solve a long standing requirement from developers to get a thread dump of an applications that run in the background as a Windows Service.

The third improvement is the "-l" option to print information about java.util.concurrent.locks. More specifically, it instructs the utility to look for ownable synchronizers in the heap. This should be useful for applications that make use of the concurrency APIs added in J2SE 5.0. Without the "-l" option the thread dump only includes information on monitors. One word of warning though, this option can be expensive if the heap is large.


Alan, that is great news. Thread dumps are one of the most important tools in customer support (may speak against the software!?). The dump going to stderr was a problem for some admins, now it's going to be much easier.

Posted by Matthias Ernst on October 14, 2005 at 03:36 AM PDT #

hi alan,

Good post.

"In that case the target processs prints a thread dump to its standard output (which can be pain if you don't know where the log file is)." -- you can run find[2] command at your root directory and find out what changed in the last x seconds. I've usually used find to help me access to all the logs that changed in the last 10 minutes eg : find /var/tomcat -mmin -3 -print (prints out all the files modified under /var/tomcat in hte last 3 minutes).

BTW, I tried copying jstack.exe from a recent mustang build on windows xp, copied it to my jdk1.5_05 BIN directory AND ran it only to find that it gave the following message and died.

Exception in thread "main" java.lang.NoClassDefFoundError: sun/tools/jstack/JStack
I guess the rt.jar in mustang should have the above missing class ?

~A BR, ~A

Posted by anjan bacchu on November 30, 2005 at 05:59 AM PST #

hi alan,

Recently, we had an junit test hanging BUT not while running it from the IDE(eclipse). Apart from instrumenting the class to find the environment/classpath, etc issues, how can I get a stackTrace of this hanging unit test.

Since ant spawns another java process for running the unit tests, (unless I modify my ant script to add JConsole related parameters on the command line for spawning the junit target and then running JConsole to get a thread dump), invoking CTRL+BREAK (on windows) does not work. Also, we're currently not able to use mustang's jstack since we're only running java 5.

any ideas ?

thank you,


Posted by anjan bacchu on November 30, 2005 at 06:04 AM PST #

Anjan - I'm not sure which operating system you are on. You mention /var/tomcat which suggests you might be on Linux or UNIX but perhaps you are on Windows with cygwin. If you are on Linux or Solaris then jstack has been included since 5.0. The one "gotta" is that you must use the version of jstack that corresponds to the application -- eg: if you are running 5.0u5 then you must use jstack from 5.0u5 to inspect the process.

If you are on Windows (you mentioned copying jstack.exe) then you are out of luck as we didn't include jstack on Windows in 5.0. In 5.0 the only way to get a thread dump is via ctrl-break on the console, or using JMX and jconsole (or some other JMX-based tool). The jstack.exe that is included in Mustang only works with 6.0, and newer, builds only - sorry. Finally, you mention a sub-process. You probably know this but "jps -l" will get you a list of the java processes.

Posted by alanb on November 30, 2005 at 07:04 PM PST #

Hi, I cannot seem to run jStack on a RH Enterprise kernel (CentOS 4.2 or RH ES Release 4). Works fine on RH 7.3. This is what I see when I run jstack on a server with RedHat Enterprise Server:
Attaching to process ID 24196, please wait... Debugger attached successfully. Server compiler detected. JVM version is 1.5.0_05-b05 Thread 24204: (state = BLOCKED) Error occurred during stack walking: sun.jvm.hotspot.debugger.DebuggerException: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.execute(LinuxDebuggerLocal.java:134) at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet(LinuxDebuggerLocal.java:437) at sun.jvm.hotspot.debugger.linux.LinuxThread.getContext(LinuxThread.java:48) at
Trancating rest of log

Posted by kenny on June 21, 2006 at 06:40 AM PDT #

Kenny - this could be: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6359295

Posted by Alan on June 21, 2006 at 05:15 PM PDT #

There is no fix mentioned in the bug even tho it is closed.

Posted by Kenny on June 22, 2006 at 07:28 AM PDT #

Look for the "Release Fixed" field which says it has been fixed in 5.0u8 b01. This is next update release which should be available later in the summer.

Posted by guest on June 22, 2006 at 04:12 PM PDT #

Great post. I was just wondering if there's a tool that helps you to analyse the stack trace in a more visual way. It's quite exhausting to scan the actual dump file on your own. I was looking at jconsole but it seems like this is only for monitoring a running process.

Posted by Mischa on March 02, 2007 at 09:16 PM PST #

I am using web start on WINDOWS xp and met a hanging issue, it seems there is no way to track the stack information of JVM.

Posted by Jumin on August 30, 2007 at 04:14 PM PDT #


Posted by guest on January 11, 2008 at 05:34 PM PST #

Very useful, theanks!

Posted by Jake on April 20, 2008 at 12:29 PM PDT #

WOW!! you made my day... Thank you so much

Posted by Kelly on April 21, 2008 at 05:42 AM PDT #

Post a Comment:
Comments are closed for this entry.



Top Tags
« July 2016

No bookmarks in folder