JDK-6296125 : JDI: Disabling an EventRequest can cause a multi-threaded debuggee to hang
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-07-13
  • Updated: 2010-12-08
  • Resolved: 2005-08-10
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.
Other JDK 6
5.0u6Fixed 6 b51Fixed
Description
See TwoThreadsTest.java in 
  /net/jano.sfbay/export/disk20/serviceability/ws/regressionTestsInWaiting/

In this test, two bkpts are set in a debuggee.  The debuggee runs
two threads, both of which hit both bkpts.
The debugger has a bkpt handler that disables both of the BreakpointRequests,
does some processing, then re-enables both BreakpointRequests.
After a few hits of the bkpts, the debuggee hangs.



###@###.### 2005-07-13 00:45:02 GMT
Comments
SUGGESTED FIX See attached webrev. ###@###.### 2005-07-19 23:22:39 GMT NOTE: The above fix was modified like this: 2c2 < * @(#)EventQueueImpl.java 1.44 05/07/14 --- > * @(#)EventQueueImpl.java 1.45 05/08/12 101a102,105 > * Note that this assumes that internal events are > * not requested with a suspend policy other than none. > * If this changes in the future, there is much > * infrastructure that needs to be updated. 104c108 < eventSet.resume(); --- > fullEventSet.resume();
19-07-2005
EVALUATION The problem is that when an event comes in from JDWP, the JDI code checks to see if there is an enabled EventRequest that matches the event. If not, then JDI thinks the event is an internal-to-JDI event so JDI doesn't deliver it to the debugger's eventQueue. Instead, JDI handles the event itself. However, JDI doesn't do an eventSet.resume() on the eventSet because internal JDI events are always SUSPEND_NONE. In this testcase, a BreakpointRequest (which is SUSPEND_ALL) is disabled _after_ the back-end code has already generated (or maybe is in the process of generating) a BreakpointEvent for that request. When the BreakpointEvent hits JDI, it is classified as an 'internal' event because there is no matching enabled BreakpointRequest, and a resume is never done as explained above. Thus, the debuggee threads are suspended, and the debugger is waiting patiently for an event that will never come. I believe this bug has always existed in JPDA. ###@###.### 2005-07-13 00:45:02 GMT
13-07-2005