RFR: JDK-8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false

[Gary Adams]

Here's another attempt to clear up the overlapping output from
the command processing and event handler in the jdb tests.

The fundamental problem is observed when "prompts"
are produced interleaved with command and event output.

This attempts to fix the issue by buffering the output and
printing it fully assembled.

  Webrev: http://cr.openjdk.java.net/~gadams/8169718/webrev.01/

On 5/26/18, 6:50 AM, gary.adams at oracle.com wrote:
> This is a review request for a previously closed test bug.
> The test was recently moved to the open repos, and the
> proposed fix is in the open code.
>
>   Webrev: http://cr.openjdk.java.net/~gadams/8169718/webrev/
>
>
> -------- Forwarded Message --------
> Subject: 	RFR: JDK-8169718: nsk/jdb/locals/locals002: ERROR: Cannot 
> find boolVar with expected value: false
> Date: 	Fri, 25 May 2018 11:35:10 -0400
> From: 	Gary Adams <gary.adams at oracle.com>
> Reply-To: 	gary.adams at oracle.com
>
> 	
>
>
>
> The jdb tests use stdin to send commands to a jdb process
> and parses the stdout to determine if a command was
> successful and when the process is prompting for new commands
> to be sent.
>
> Some commands are synchronous, so when the command is completed
> a new prompt is sent back immediately.
>
> Some commands are asynchronous, so there could be a delay
> until a breakpoint is reached. The event handler then sends a prompt
> when the application thread is stopped and new jdb commands can be sent.
>
> The problem causing the intermittent failures was a corruption in the
> output stream when prompts were being sent at the wrong times.
>
> Instead of receiving
>    "Breakpoint hit:"<location>
>     <prompt>
>
> the log contained
>    "Breakpoint hit:"<prompt>  <location>
>
> Once out of sync, jdb commands were being sent prematurely
> and the wrong values were being compared against expected behavior.
> The simple fix proposed here recognizes that commands like "cont",
> "step" and "next" are asynchronous commands and should not send back
> a prompt immediately. Instead. the event handler will deliver the next prompt
> when the next "Breakpoint hit:" or "Step completed:" state change occurs.
>
> The bulk of the testing was done on windows-x64-debug builds where the
> intermittent failures were observed in ~5 in 1000 testruns. The fix has
> also been tested on linux-x64-debug, solaris-sparcv9-debug,
> and macosx-x64-debug, even though the failures have never been reported
> against those platforms.
>
> Failures have been observed in many of the nsk/jdb tests with similar corrupted
> output streams, but never directly associated with this issue before.
>
>   redefine001, caught_exception002, locals002, eval001, next001,
>   stop_at003, step002, print002, trace001, step_up001, read001,
>   clear004, kill001, set001
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180720/1b42a9b7/attachment.html>