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
