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

[gary.adams at oracle.com]

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/20180526/f8cb91a0/attachment.html>