JDK-8149081 : com/sun/jdi/RedefineChangeClassOrder.sh fails intermittently
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2016-02-05
  • Updated: 2016-07-28
  • Resolved: 2016-05-04
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 9
9Resolved
Related Reports
Duplicate :  
JDK-8149083 - com/sun/jdi/CommandCommentDelimiter.sh fails intermittently
Duplicate :  
JDK-8154144 - Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely"
Relates :  
JDK-8154144 - Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely"
Description
com/sun/jdi/RedefineChangeClassOrder.sh fails intermittently, with high frequency (especially on Solaris)

<cleanup:_begin_failFile_contents>
 
--Fail: main: jdb input stream closed prematurely
<cleanup:_end_failFile_contents>
Comments
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
[To: Sharath ] Updating the bug report with comments reflecting a state of investigation is a good style. People can help you with an advice or ideas when it is possible.
01-04-2016
I am able to recreate this issue on a solaris VM. I run the testcase for 200 times and it fails once. I don't see much difference between the passing and failing case. In the failing case also the testcase runs to completion but fails with the "Input stream closed. " error. Investigating further.
01-04-2016
ILW = M (test noise) M (intermittent) H (no workaround) = P3
08-02-2016