Bug 174158

Description Jan Dostert 2007-02-14 08:24:47 EST

Build ID: M20060921-0945

Steps To Reproduce:
Hi,

when a thread is started and suspended by the VM directly after it has been started, the suspend state of the thread is not displayed correctly in the debug view.
The debug view shows the thread as running, although it's suspended.

The following JWDP-packets are sent/received by the VM:

JDWP: --------------------------------------------
JDWP: SEND Command Packet (id = 2)
JDWP: suspendPolicy: 0 (NONE)
JDWP: events : 1
JDWP:         eventKind : JDWP_EVENT(THREAD_START)
JDWP:         requestID : 3
JDWP:         thread : id=25980 name=Working Thread
JDWP: --------------------------------------------
JDWP: RECV Command Packet (id = 10960)
JDWP: thread : id=25980 name=Working Thread
JDWP: CommandSet 11 (ThreadReference), Command 4(Status)
JDWP: --------------------------------------------
JDWP: SEND Reply Packet (id = 10960, error = 0 [NONE])
JDWP: threadStatus : 1 (RUNNING)
JDWP: suspendStatus : 1
JDWP: --------------------------------------------

The VM sends the THREAD_START event. After the thread has been started, the thread is suspended by the VM.
The eclipse debugger queries the status of the thread to display the thread in the debug view.
The VM replies that the thread is suspended. Nevertheless the thread is shown as running in the debug view of eclipse.

The reason for this behavior seems to be related to the bug fix for bug 120385:

The coding below shows a special treatment for the suspend state. Although the VM reports that the thread is suspended,
the thread is displayed as running when no breakpoints exist.


org.eclipse.jdt.internal.debug.core.model.JDIThread

protected void initialize() throws ObjectCollectedException {
    ...
    try {
	boolean suspended = getUnderlyingThread().isSuspended();
	if (suspended) {
	    // Unless we're at a breakpoint, set status to running. The thread state
	    // will be properly updated to suspended in the case that a breakpoint
	    // is hit. Otherwise this is likely just a transient suspend state (for
	    // example, a breakpoint is handling a class prepare event quietly).
	    // See bug 120385
	    suspended = getBreakpoints().length > 0;
	}
	setRunning(!suspended);
    } catch (VMDisconnectedException e) {
    }

Regards,
Jan

More information: