Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8154144

Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely"

    Details

    • Resolved In Build:
      b120

      Backports

        Description

        Different shell tests that resides under com/sun/jdi fails with the same symptoms - "jdb input stream closed prematurely"

          Issue Links

            Activity

            Hide
            dcubed Daniel Daugherty added a comment -
            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.
            Show
            dcubed Daniel Daugherty added a comment - 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.
            Hide
            sballal Sharath Ballal added a comment -
            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 }
            Show
            sballal Sharath Ballal added a comment - 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 }
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/hs/jdk/rev/73608cd4f89a
            User: dsamersoff
            Date: 2016-05-06 10:07:13 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/hs/jdk/rev/73608cd4f89a User: dsamersoff Date: 2016-05-06 10:07:13 +0000
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/73608cd4f89a
            User: lana
            Date: 2016-05-25 17:36:43 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/73608cd4f89a User: lana Date: 2016-05-25 17:36:43 +0000
            Hide
            mcastegr Mattis Castegren (Inactive) added a comment -
            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
            Show
            mcastegr Mattis Castegren (Inactive) added a comment - 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
            Hide
            afomin Alexander Fomin (Inactive) added a comment -
            UR SQE OK to defer it.
            Show
            afomin Alexander Fomin (Inactive) added a comment - UR SQE OK to defer it.

              People

              • Assignee:
                sballal Sharath Ballal
                Reporter:
                dsamersoff Dmitry Samersoff (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                9 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: