Stack trace in Java

Command Line

If the application is running as a console application, you can try one of these:

Sending a signal to the Java Virtual Machine

On UNIX platforms you can send a signal to a program by using the kill command. This is the quit signal, which is handled by the JVM. For example, on Solaris you can use the command kill -QUIT process_id, where process_id is the process number of your Java program.

Alternatively you can enter the key sequence <ctrl>\ in the window where the Java program was started. Sending this signal instructs a signal handler in the JVM, to recursively print out all the information on the threads and monitors inside the JVM.

To generate a stack trace on Windows, enter the key sequence <ctrl><break> in the window where the Java program is running, or click the Close button on the window.
(Excerpt from http://java.sun.com/developer/technicalArticles/Programming/Stacktrace/)

If the application is not running in a console, you can use the jstack tool that ships with J2EE since 1.5

jstack [ option ] pid
jstack [ option ] executable core
jstack [ option ] [server-id@]remote-hostname-or-IP

GUI Tools

Since the JVM provides APIs to hook in and get the thread state and other information, there are several tools in the market that allows you to see the state of the running application including the thread stack trace. One such freely available option is VisualVM. In fact it ships with JDK these days. Although VisualVM is pretty self explanatory, here are some instructions to get you started. http://docs.oracle.com/javase/6/docs/technotes/guides/visualvm/threads.html

You could also use jConsole for similar purpose, but I prefer VisualVM. Check this for more information: http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html#DeadlockDetection

Programmatically capturing the stack trace

from within an appilcation, you can call : Thread.getAllStackTraces(). But if you want to do the same from a different application, ThreadMXBean exposes the needed data, which can be retrieved by using the JMX interface.

Dumping thread Stack trace in .NET

.NET does not seem to have the variety of options like Java. The only reasonable option I have seen so far is the Managed Stack Explorer. This can be run from the command line as

mse /s /p <pid>

or as a GUI application:

Since it is an open source (MSPL) project, I took a peek into its source to check the API used. It depends on some sample code released by the CLR Team called mdbg. This in turn is a managed layer on the unmanaged CLR Debugging Services API.

From what I see there seems to be no direct way to get a stack trace in .NET, apart from either using the debugger API, or rolling your own on top of the StackTrace class. Check this question on StackOverflow.

Here is a list of programming languages available on these runtimes.

1. Can run on CLI using IKVM.NET
2. Can run on JVM using Mainsoft solution
3. Not yet usable
4. Can run on CLR, but is behind the JVM implementation

The main reason for the research was to identify a new language I should pick-up. I looked at Python and Ruby, but both have some sore thumbs that I just can’t stand. I really liked Boo and Groovy; they are similar to C#/Java in syntax and incorporate the good things from Python. Although I like Boo’s syntax and approach more than Groovy, Groovy has a more mature implementation and ecosystem. I will try to use Groovy for some hobby project and get a feel to things.