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

[Gary Adams]

Looking for one more reviewer before we push this changeset.

On 9/22/18, 6:45 AM, gary.adams at oracle.com wrote:
> This is a very old bug that started off as a closed test, but should 
> have an open review
> before it finally gets pushed. Many other jdb bugs will be closed as 
> duplicates as a
> result of this change.
>
> The problem shows up as a corrupted log when running the jdb tests.
> The tests send commands to a jdb process and parse the output to determine
> if the correct functions were performed. Sometimes the tests will timeout,
> sometimes the test will report the commands were not successful.
>
> When running jdb the output can come from several different threads.
>     - the command processing thread
>     - the event handler thread
>     - asynchronous command threads
>     - debuggee class (separate process)
>
> This fix works around an issue between the command
> thread and the event handler thread. In the TTY.executeCommand()
> method there is a large dispatch to commands that ends with the printing
> of a prompt for the user to enter another command.
>
> When commands {cont, next, step, stepi} are processed they
> resume the vm in the debuggee. This can cause the event handler
> to be woken up. Events typically display messages, such
> as "Breakpoint hit", "Step completed". They also set the
> current thread variable so a "current location" in the source can
> be identified. The event finishes by printing a prompt so the user will
> enter the next command.
>
> The corruption in the log shows up when the event handler
> starts running between the printing of the command and
> command issuing the prompt. It also shows up when
> a prompt is written in the middle of the event output.
>
> The proposed fix allows the {cont,next,step,stepi} commands
> to issue a simple prompt before performing the command
> that resumes the debuggee. It then skips the prompt that is issued
> at the end of the excuteCommand() dispatch.
>
> A variety of other fixes had been tried such as locks and
> output buffering, but all fell short. Many of the output
> routines are shared. Even the executeCommand() processing
> is called from the event handler thread to process monitor
> commands.
>
>   Webrev: http://cr.openjdk.java.net/~gadams/8169718/webrev.03/
>
> This fix was tested with 1000 test runs on the slower debug builds
> where the problem was observed more often. Before the fix it was
> common to see 9/1000 failures on windows-x64 and solaris-sparc9
> platforms.
>
> Here's a sample of a corrupted log. A prompt is displayed after
> an event header was displayed. As the next command is processed
> the rest of the event output shows up.
> ...
> Breakpoint hit: main[1]
> Sending command: locals
>
> reply[0]: "thread=main", 
> nsk.jdb.locals.locals002.locals002a.allKindsOfLocals(), line=82 bci=62
> ...

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