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

VM started with application hangs after quitting from the remote debugger

    XMLWordPrintable

Details

    • b01
    • x86
    • generic
    • Not verified

    Backports

      Description

        Please work with the enclosed package Design.new. Compile the test using the
        command compile.bat, and then run it by run.bat. Then, attach to the VM with JDB
        (jdb -password xxxxx), and follow the steps as below.

        You should be able to reproduce the symptom by performing all of the steps
        stated as below, and then at the end (after you quit JDB) do a q in the run.bat
        window to quit. The VM will throw an exception and hang.

        The test case is performed in the following way:

        Start run.bat, and then attach it the VM with JDB. You should have two windows,
        run.bat and JDB, open.

        1] hit 1 to load the class in run.bat window,
        2] set the breakpoint in JDB window, (stop at CNdTestClass:9)
        3] hit 3 to call the method in run.bat. (no classes are GCed)
        4] clear the breakpoint in JDB window (clear CNdTestClass:9)
        5] cont (to resume execution) in JDB window
        6] quit in JDB window
        7] hit 2 to unload the class in run.bat

        Now restart jdb. After the reloading CNdTestClass (entering '1' in the
        run.bat window), a "classes" command will list 2 instances of CNdTestClass.
        The breakpoint should be set on the second CNdTestClass to be loaded in JDB
        window.

        Repeating steps #2 through #6, CNdTestClass will be GC'd (Yes, it will
        lag one behind) In the NetDynamics' production environment,
        Remote.debugger.close() maybe called to do the same thing as our step #6 (quit)

        Then, execute quit 'q' in run.bat window, you will notice the socket exception
        "Internal debug-agent error: java.net.SocketException Connection reset by peer"
        (in run.bat window), and the JVM started with run.bat should hang.

        Another simple problem scenario should also taken into consideration...

        Just follow the steps #1 through #7. Then, immediately do q in run.bat window,
        you will notice that the JVM does not exit properly, and eventually you will see
        "Internal debug-agent error: java.net.SocketException Connection reset by peer"
        and then the hang.

        sandhya.vora@Eng 1998-01-26
        The synopsis is re-written from 'remote debugger VM hangs at exit with socket exception' to VM started with application hangs after quitting from the remote debugger'. I think, this better describes the problem.

        erik.larsen@eng (for sandhay.vora@eng) 1998-01-28
        Here is some additional information from Sandhya Vora:
        We were able to come up with a simple test scenario to demonstrate the problem.

        1] In first MSDOS shell (call the run.bat window), run the script
        run.bat
        (displays the password as 5kzze)

        2] In second MSDOS shell (call the JDB window), type the command
        jdb -password 5kzze
        (displays the prompt)

        3] In JDB window, type quit

        4] In run.bat window, type q

        You will notice that the application started in run.bat window does not exit properly.

        erik.larsen@eng 1998-01-28
        error message:
        [Internal debug-agent error: java.net.SocketException Connection reset by peer
         at java.net.SocketOutputStream.write(SocketOutputStream.java:91)
         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81
         )
         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
         at java.io.DataOutputStream.flush(DataOutputStream.java:100)
         at sun.tools.debug.BreakpointHandler.run(BreakpointHandler.java:264)
         ]
        Reproducing this with the test case we have been using is just a matter
        of launching jdb (no breakpoints, or the loading of any classes) , quiting
        jdb immediatly and attempting to quit the test case.

        sandhya.vora@Eng 1998-01-29
        Just one more bit of information for you. I have tested the simplified case (as above, in the section dated 01-28) on Solaris across the various versions of JDK from 1.1.1 to 1.1.6, and the test seems to work across the JDK versions. Therefore, this really never was a problem / bug on Solaris side. On Windows side, I believe that this problem remains across the JDK versions.

        Attachments

          Issue Links

            Activity

              People

                ghirschsunw Gordon Hirsch (Inactive)
                duke J. Duke
                Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: