SUGGESTED FIX

See attached webrev.
                                     

SUGGESTED FIX

The fix is to remember the thread from events that are filtered out
so it can be used to do a Thread.resume in the case where 
it is a SUSPEND_EVENT_THREAD type of EventSet.
                                     

EVALUATION

The problem is EventSetImpl.build.  The code filters out Events
for which no enabled request can be found.  It then notices that the 
resulting EventSet is empty, and then calls EventSet.resume()
to resume the debuggee.   If it is a SUSPEND_ALL EventSet, this is fine.
But if it is a SUSPEND_EVENT_TREAD EventSet, then resume() searches
thru the EventSet to find an Event from which it can get the thread
to be resumed.  But, the EventSet is empty so resume() thows  InternalException("Inconsistent suspend policy");
                                     

EVALUATION

This bug is related to:
   6296125 JDI: Disabling an EventRequest can cause a multi-threaded debuggee to hang
   6293795 Backend hangs when invokeMethod is called from a JDI eventHandler

I think it is actually caused by the fix for 6293795 - at least the testcase doesn't fail before 5.0_10 which contains the fix for 6293795. I suspect that some problems could still occur in those earlier releases, but haven't looked for them.

The problem only occurs when a debugger enables an EventRequest on 
a thread/threads that are already running, and it is a SUSPEND_THREAD request.

In this case, there
is a window in the JDI code where it has sent the JDWP enable-event command to
the back-end, but has not yet gotten back the response from the back-end and completed setting  up the EventRequest. If the running thread triggers the
event inside this window, the event cannot be matched to the not-yet-completed EventRequest which causes the EventHandler in the JDI code to mis-behave and throw the exception shown.