|
Yes, I pretty much had concluded the
same, but would be nice to have an actual stacktrace of the
exception to be sure. In fact by default I think this test should
be printing the exception before failing, not just including the
exception message in the error message.
thanks,
Chris
On 4/19/19 11:24 AM, Gary Adams wrote:
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
|
