Looks good.
--alex
On 08/29/2018 21:19, Chris Plummer wrote:
Hi,
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8210118
http://cr.openjdk.java.net/~cjplummer/8210118/webrev.00/
There have a been a few jdb bugs (or test bugs) that have caused tests
to fail because they never get the expected jdb prompt. The only clue in
the log is an abrupt termination of any jdb output, and the following
error message:
# ERROR: Caught unexpected exception while executing the test:
nsk.share.Failure: Prompt is not received during 300200 milliseconds.
Dumping the pending reply makes it a lot easier to debug most of these
failures. Here's one example output with the fix in place:
Sending command: cont
receiveReply FAILED due to "nsk.share.Failure: Prompt is not received
during 300200 milliseconds.".
Pending reply output follows:
reply[0]: >
reply[1]: Breakpoint hit: Arg"thread=main",
nsk.jdb.locals.locals002.locals002a.allKindsOfLocals(), line=100 bci=62
reply[2]: umen100 System.out.println("Locals but no
arguments"); // locals002.BREAKPOINT_LINE2
reply[3]:
reply[4]: ts bmain[1] ut no locals
# ERROR: Caught unexpected exception while executing the test:
nsk.share.Failure: Prompt is not received during 300200 milliseconds.
In this case we can see all sorts of extra characters in various reply
lines. These characters actually come from a println that was executed
after execution resumed and before the next breakpoint:
System.out.println("Arguments but no locals"); //
locals002.BREAKPOINT_LINE1
Having the pending reply helps a lot here. Without it, you have no idea
why the main[1] prompt was never seen and might be led to think it was
never sent. By looking at the pending output you can see that main[1]
was sent, but it not being detected because of all the extra characters
appearing on the same line.
thanks,
Chris
