Kbase 20028: How to Examine a Java Stack Trace
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
16/10/2008 |
|
Status: Unverified
GOAL:
How to examine a Java stack trace?
FIX:
Review the following information within a Java Stack Trace:
Current thread:
Theoretically the current thread is the last thread that was running when the stack trace snapshot is taken.
Often the current thread is labeled "current thread" next to the appropriate thread. Unfortunately, sometimes, it represents a good guess by the signal handler.
Sometimes the signal handler is marked as the current thread, which doesn't help your diagnosis at all! On some platforms, none of the threads are marked as the current thread.
More evidence about which thread is the current thread is explained in the "Examining Monitors" section of this solution below.
Runnable threads:
Track down all the threads that have a state of Runnable (R). Threads in the R state were running or were ready to run the next time 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, some native code within the application or the JVM was most likely to blame.
If a core file is present and the OS is Unix use the following command to find out which JDKTM software it came from:
strings core | grep JAVA_HOME
Determining the thread states:
Many different threads in many different states can be seen in a snapshot from a JVM stack trace. Use the following key to determine the state of the thread:
R = Running or runnable thread.
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.
Normally only threads in R, S, CW or MW appear in the stack trace.
If a thread is in MS state, report it to Sun Microsystems because there is a good chance it is a bug.
Most of the time a thread in Monitor Wait state will appear in the S state (suspended).
Examining Monitors:
Where the threads section of a stack trace identifies the multi-threaded part of your application, the monitors section represents the parts of your application that are single-threaded (monitors manage access to code that should only be run by a single thread).
In your Java code only one thread can have the lock to a synchronized piece of code at a time. All the other threads queue up to enter the synchronized code.
A monitor can be thought of as a lock on an object, and every object has a monitor.
When you generate a stack trace, monitors are listed as being either registered or not registered. In the majority of cases the registered monitors (or system monitors) are not the cause of your software problems.
Because only one thread can enter a synchronized block at a time, other threads queue up at the start of the synchronized code and appear as thread state MW. In the monitor cache dump they are denoted as "waiting to enter" threads. In user code, a monitor is called into action wherever a synchronized block or method is
used.
Any code waiting on an object or event (a wait method) also has to be inside a synchronized block. However once the wait method is called, the lock on the synchronized object is given up.
When the thread in the wait state is notified of an event to the object, it has to compete for exclusive access to that object and it has to obtain the monitor. Even when a thread has sent a "notify event" to the waiting threads, none of the waiting threads can actually gain control of the monitor lock until the notifying thread has left its synchronized code block.
"Waiting to be notified" is seen for threads at the wait method