JDK-6459476 : Debuggee is blocked, looks like running, but no further steps can be performed
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 5.0u6,7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,linux_2.6
  • CPU: generic,x86
  • Submitted: 2006-08-11
  • Updated: 2011-05-13
  • Resolved: 2007-07-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u2Fixed 7 b12Fixed
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.
01-07-2007
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.
08-03-2007
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.
08-03-2007