However, regardless of the size of the stack trace there are a few key things that anyone can find to help diagnose most Java software problems, whether you are a Java programming expert or very new to the Java platform.
Three popular ways to generate a Java stack trace:
1. Sending a signal to the JVM
2. The JVM generates a stack trace for you
3. Using debugging tools or Java API calls.
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 95, or Windows NT platforms, enter the key sequence <ctrl><break> in the window where the Java program is running, or click the Close button on the window.
2. The Java Virtual Machine generates a stack trace for you
If the JVM experienced an internal error, for example a segmentation violation or an illegal page fault, it will call its own signal handler to print out the threads and monitors information.
3.Using debugging tools or Java API calls
You can generate a partial Java stack trace, which in this case is only the threads information, by using the Thread.dumpStack method, or the printStackTrace method of the Throwable class. You can also obtain similar information by entering the command "where" inside the Java debugger.
By following the next three steps you might find the solution to the application's problem without any more analysis. However, if you don't, the evidence you'll gain from this exercise is vital to any further investigation.
Finding the current thread
You now have a Java stack trace. The first piece of information you need to look for is the current thread. In theory the current thread should be the last thread that was running when the snapshot was taken. If you have seen a Java stack trace before you may have noticed that often the current thread is labeled *current thread* next to the appropriate thread.
Note:If you see the label Compiled Code next to the current thread then this stack trace came from a JVM using the JIT compiler. If possible generate another stack trace without the JIT enabled using the -nojit parameter to the JVM.
Runnable threads
Next you need to track down all the threads that have a state of R, which stands for Runnable. Threads in the R state were running, or were ready to run the next time the threads were scheduled. Make a note of these, because they could indicate where your problem lies.
Core files
If the JVM generated the stack trace because of an internal error then some native code in your own application, or the JVM was probably to blame. If you are using UNIX, and you find a core file, run the following command to find out which JDKTM software it came from:
strings core | grep JAVA_HOME
In the JDK 1.2 software release, threads that called methods resulting in a call to native code are indicated in the stack trace.
S Suspended thread
CW Thread waiting on a condition variable
MW Thread waiting on a monitor lock
MS Thread suspended waiting on a monitor lock
An Introduction to JavaTM Stack Traces
http://developer.java.sun.com/developer/technicalArticles/Programming/Stacktrace/
Analyzing Stack Traces http://developer.java.sun.com/developer/onlineTraining/Programming/JDCBook/stack.html