JDK-8210748 : [TESTBUG] lib.jdb.Jdb.waitForPrompt() should clarify which output is the pending reply after a timeout
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 12
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-09-14
  • Updated: 2020-08-27
  • Resolved: 2018-09-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 12
11.0.10-oracleFixed 12 b13Fixed
Related Reports
Relates :  
JDK-8210118 - better jdb test diagnostics when getting "Prompt is not received during ... milliseconds" failures
Relates :  
JDK-8210725 - com/sun/jdi/RedefineClearBreakpoint.java fails with waitForPrompt timed out after 60 seconds
Description
This enhancement suggestion is the same as what was done for JDK-8210118, but in this case it is applied to the test/jdk version of waitForPrompt() instead of the nsk/jdb version.

Note for JDK-8210118 the dumping of the pending reply was done in receiveReply() after waitForPrompt() timed out, but it might be more appropriate to do it in waitForPrompt(). I had considered this for JDK-8210118, but only after having already implemented and extensively tested the fix in receiveReply(), so I just left the code there.
Comments
Fix Request (11u) This backport improves testing and matches the codebases better (I see 11.0.10-oracle). Patch applies cleanly to 11u, com/sun/jdi tests pass in {fastdebug,release}. This bunch contains a rewrite and a few follow-ups: JDK-8210560, JDK-8210725, JDK-8210748.
25-08-2020
You're right, it is already printed. I missed that because there is no indication of error or failure before it does that, so you cant distinguished between normal jdb reply output and the reply output that was pending when the error occurred. The reply output looks just like normal output, with the error message coming after it. So I think what is needed is an error message just before printing the pending reply like was done for JDK-8210118.
14-09-2018
waitForPrompt() does dump pending reply (reply without EOL) in the case of throwing exception. But after throwing exception the framework performs cleanup (sends "quit" to jdb), and output from the cleanup is logged to the standard output, so it's hard to detect certain point where the error occurs. Need to update the logging to make simpler error analysis
14-09-2018