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();
                                     

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