RFR(S): JDK-8210118: better jdb test diagnostics when getting "Prompt is not received during ... milliseconds" failures

[Chris Plummer]

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