RFR: JDK-8222741: jdi/EventQueue/remove/remove004 fails due to VMDisconnectedException

[Gary Adams]

 From the CR :


--> debugger: -----t2: method 'run' exit

Thead2 from the debugger process has completed. remove004.java:531

debugee.stderr> **> debuggee: after: Thread.sleep

Debuggee process has completed the sleep operation.  remove004a.java:113

--> debugger: breakpointForCommunication

Debugger main thread has passed the breakpoint event check.
   remove004.java:315 breakpointForCommunication:479
   remove004a.java:120 methodForCommunication

Since  VMDisconnectedException is a RunTimeException,
it may have been thrown during the breakpointForCommunication
processing or in the debuggeeClass.getValue field lookup.

# ERROR: ##> debugger: ERROR: VMDisconnectedException : 
com.sun.jdi.VMDisconnectedException
The following stacktrace is for failure analysis.
nsk.share.TestFailure: ##> debugger: ERROR: VMDisconnectedException : 
com.sun.jdi.VMDisconnectedException
at nsk.share.Log.logExceptionForFailureAnalysis(Log.java:428)
at nsk.share.Log.complain(Log.java:399)
at nsk.jdi.EventQueue.remove.remove004.log3(remove004.java:120)
at nsk.jdi.EventQueue.remove.remove004.runTest(remove004.java:262)
at nsk.jdi.EventQueue.remove.remove004.runThis(remove004.java:195)
at nsk.jdi.EventQueue.remove.remove004.run(remove004.java:101)

The VMDisconnectedException is caught in runTest:262 which
was processing the testRun:252 steps where the proposed change
would be placed. If the failure was detected in the final steps
confirming the VMDeathEvent, then we would have seen the
log message at remove004.java:254.

On 4/19/19, 1:58 PM, Chris Plummer wrote:
> Hi Gary,
>
> Can you add the backtrace of the exception to the CR. It will make it 
> a bit easier to understand when/why this bug is happening.
>
> If I understand correctly, the second time through the loop the 
> debuggee should be at a breakpoint, but we do the vm.resume() before 
> we check for the breakpoint event, and this sometimes leads to the 
> debuggee exiting before the call to eventIterator.nextEvent(), and 
> this is where the exception occurs.
>
> Also, I assume with the old implementation that the vm.resume() done 
> at lines 321 or 329 actually is not doing anything on the 2nd and 
> subsequent iterations since the debuggee is already resumed by the 
> resume() at the top of the loop. With your fix, they now are providing 
> a needed resume().
>
> If my understanding is correct, then your fix looks good.
>
> thanks,
>
> Chris
>
> On 4/19/19 10:06 AM, Gary Adams wrote:
>> Prevent the debuggee from exiting too quickly by
>> holding it at the breakpoint until the end of processing
>> flag has been read by the main thread from the debugger process.
>>
>>   Webrev: http://cr.openjdk.java.net/~gadams/8222741/webrev/
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8222741
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190419/f3c68be9/attachment-0001.html>