• Type: Bug
• Component: core-svc
• Affected Version: 7u111,8u40,9

• Priority: P3
• Status: Resolved
• Resolution: Fixed

• Submitted: 2016-04-13
• Updated: 2016-10-13
• Resolved: 2016-05-06

JDK 7	JDK 8	JDK 9
7u121Fixed	8u112Fixed	9 b120Fixed

UR SQE OK to defer it. 06-06-2016 JDK-8067354 was marked as a P4. The fixes are all in share/classes/com/sun/tools/example/debug/tty. This is not critical for the July release, adding a defer request since this is a P3. This is not critical for JDK 7 and 8, but there are quite a few test bugs closed as duplicates of this, so this could reduce noise in testing. Therefore, opening backports to 7 and 8 for the October release 01-06-2016 The root cause of this problem is that BufferedReader.readLine() is returning 'null' during System.exit(0). I analyzed the following code by putting print statements and found that in TTY.java:751 we are always blocking on readLine(). Whenever a user enters a command in JDB, the readLine() returns the command, which gets executed. This is running in the 'main' thread. When JDB is done, as part of the shutdown it calls System.exit() at Env.java:92 in a different thread 'event-handler'. Usually (in the passing cases) calling System.exit() is the end of the process and readLine() doesn't return 'null', but in the failing case readLine() at TTY.java:751 returns 'null'. This causes the string "Input stream closed." to be printed. The jtreg testcase looks for this string to decide that the testcase failed. I also observed that putting a print statement before System.exit() does not cause this problem. I did a successful run of 200 jtreg runs. I will do one more round of tests tomorrow. So far I have not seen this problem on linux, it fails on solaris. jdk/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java 708 BufferedReader in = 709 new BufferedReader(new InputStreamReader(System.in)); ....... ....... 748 // Process interactive commands. 749 MessageOutput.printPrompt(); 750 while (true) { 751 String ln = in.readLine(); 752 if (ln == null) { 753 MessageOutput.println("Input stream closed."); 754 ln = "quit"; 755 } jdk/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Env.java 79 static void shutdown(String message) { 80 if (connection != null) { 81 try { 82 connection.disposeVM(); 83 } catch (VMDisconnectedException e) { 84 // Shutting down after the VM has gone away. This is 85 // not an error, and we just ignore it. 86 } 87 } 88 if (message != null) { 89 MessageOutput.lnprint(message); 90 MessageOutput.println(); 91 } 92 System.exit(0); 93 } 14-04-2016 My personal hip pocket theory about this failure mode over the years was that the tests were running off the end of main(). Sometimes the debuggee's main() thread finishes and the debuggee VM shuts down before the debugger is ready for that. Sometimes the debuggee's main() thread takes a little bit longer and the debugger gets to the "I'm done testing" phase and can handle the debuggee VM going away. One possible solution is to add a breakpoint after main() returns and change the debuggee <-> debugger protocol to always expect one final breakpoint. Positive enforcement that the test reaches that point and it should catch any accidental "run of the end of main()" issues. 13-04-2016