United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6459476 Debuggee is blocked, looks like running, but no further steps can be performed
6459476 : Debuggee is blocked, looks like running, but no further steps can be performed

Details
Type:
Bug
Submit Date:
2006-08-11
Status:
Resolved
Updated Date:
2011-05-13
Project Name:
JDK
Resolved Date:
2007-07-01
Component:
core-svc
OS:
generic,linux_2.6
Sub-Component:
debugger
CPU:
x86,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
5.0u6,7
Fixed Versions:
7

Related Reports
Backport:
JDK-2147590 - Debuggee is blocked, looks like running, but no further steps can be performed

Sub Tasks

Description
The attached application demonstrates that after few steps the debugger stops working and no further step events are generated by the back-end. Resume does not help, since after suspend the program remains in the same state.

Steps to reproduce:
- unzip the attached deadlockingApp.zip into an empty folder.
- execute ./run in some terminal window
- in an other terminal window, go the folder where deadlockingApp.zip was unzipped and follow the instructions in jdb.HOWTO

What is going on:
The debuggee starts up and run one more instance of itself, now with some arguments. This is in HandlerImpl.execSecondInstance(). After the second instance starts up, is creates a socket communication with the first one and passes some arguments to it. Then it ends. The first instance is being debugged right after this communication. After several steps it usually freezes. StepEvent does not come, several iterations of suspend/resume do nothing. If this does not happen the first time, repeat the whole process once more, it will certainly happen.

It might be important to mention that the freeze can not be reproduced without the second instance of the application. Therefore the code that performs the communication (combined with the debugger intervention) probably does something that cause the debuggee to stop responding.

Comments
EVALUATION

This fix went into JDK 7 b12, but I missed the final step of
marking the bug report 10-Fix Delivered.
2007-07-01 
EVALUATION

The hang occurs because the user thread is in the JPDA back-end code
and has created a SingleStep command, put it on the queue to be
processed and is waiting to be notified on the commandCompleteLock.
The event helper thread has removed the command from the queue,
processed it, and notified(all) the commandCompleteLock.  At the 'same
time' as this is happening a different user thread does a Thread.interrupt
on the user thread that is waiting on commandCompleteLock.

The problem is in function debugMonitorWait in back-end file util.c.
This function calls JVM TI RawMonitorWait.
If this call completes with a JVMTI_ERROR_INTERRUPTED (because some
user code has called Thread.interrupt()), the debugMonitorWait
loops and calls RawMonitorWait again.  However, if a notify
occurs at 'the same time' as the interrupt, then that notify can be lost.
The thread will wait for ever.
2007-03-08 
SUGGESTED FIX

The fix is to change the debugMonitorWait functions in the back-end to
not loop when their calls to JVM TI RawMonitorWait complete with
JVMTI_ERROR_INTERRUPT.  Instead they should return as if a notify had 
occured.  See attached webrev.

Note that this return has to be ok even if a notify didn't really occur,
because the JLS says that a VM may do 'spurious' wakeups on waiting
threads, IE, a debugMonitorWait caller has to behave correctly 
if debugMonitorWait returns when a notify has not occured.
And, the callers do behave correctly - they check that the
condition they waited for really did occur, and if it didn't,
they call debugMonitorWait again.
2007-03-08


Hardware and Software, Engineered to Work Together