Currently Jdb.waitForMessage() does the following if it timeouts out before receiving the expected reply:

          log.display("WARNING: message not recieved: " + message);
          log.display("Remaining debugger output follows:");
          receiveReply(startPos);

The purpose of calling receiveReply() is to aid in debugging the failure by dumping whatever reply has been received so far. The problem is that waitForMessage() calls waitForPrompt(), so this results in waiting for the next prompt, which we don't want to do. It results in confusing output like the following:

Sending command: cont
WARNING: message not recieved: MyThread-0[1]
Remaining debugger output follows:
reply[0]:>
reply[1]: Method exited: return value =<void value>, "thread=MyThread-0", nsk.jdb.exclude.exclude001.MyThread.run(), line=93 bci=14
reply[2]: 93 }
reply[3]:
reply[4]: MyThread-0[1]
# ERROR: Caught unexpected exception while executing the test: nsk.share.Failure: Expected message not received during 420200 milliseconds:
...

In this test failure, waitForMessage() timed out looking for MyThread-0[1]. However, MyThread-0[1] is in the reply buffer. The bug in this test was that the timeout was not long enough, and eventually MyThread-0[1] does arrive, but it does so during the waitForPrompt() call done by receiveReply(). So the log looks odd since it appears that MyThread-0[1] did not arrive, but the reply dump shows that it did. The reality is that "reply[4]: MyThread-0[1]" should not have appeared in the log because it was not present at the time the timeout happened.

waitForMessage() should instead call receiveReply() as follows:

   receiveReply(startPos, false, 0);

And then receiveReply() should be fixed to not call waitForPrompt() if the prompt count is 0. receiveReply() would still end up printing additional output that arrived after the timeout, but the likelihood of any output arriving during this time is almost zero.