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

JDI: Internal JDI helper threads should setDaemon(true)

XMLWordPrintable

    • hopper
    • generic
    • generic
    • Verified



        Name: tb29552 Date: 10/11/2001


        ------------- Begin Forwarded Message -------------

        Date: Wed, 10 Oct 2001 17:22:59 -0700
         From: <###@###.###>
         To: <###@###.###>
        CC: ###@###.###, ###@###.###
         Subject: Re: Request for clarification of JDI implementation issue

        I,
        Sorry I overlooked your email.

        Without any analysis or testing, your suggestion that these threads
        be daemon threads seems correct. In fact, I am suprised at two things,
        first, that they aren't currently daemon threads and, second, that we
        have not noticed this problem before.

        The workaround I suggested in the last email, I think, still should
        be applied because tests can hang for other reasons.

        Team,
        Is someone able to look at this?

        -R

        "I" wrote:
        >
        > R,
        >
        > I'm from Nsk test development team.
        > I request you to clarify an issue of the implementation of JDI in Merlin.
        >
        > I wrote a simple JDI test that launches debuggee and just returns from main().
        > However, the test does not actually exit, but it waits until debuggee
        > finishes. If debuggee works infinitely, test never exits.
        >
        > To see why it happens, I started the test under jdb. After main() had been
        > completed, I suspended the debuggee and looked at the list of running threads.
        > I discovered a couple of threads:
        >
        > Group JDI [2766626]:
        > (java.lang.Thread)0xd6 JDI Target VM Interface running
        > (java.lang.Thread)0xc9 JDI Internal Event Handler cond. waiting
        >
        > I suppose, these threads (or at least one of them) are not daemon, so JVM
        > waits for them even if main() has completed. Hovewer, these threads do not
        > finish until debuggee exits. Only invoking of System.exit() in debugger or
        > killing the debuggee process permits JVM to exit immediately.
        >
        > Could you tell me, is such behaviour of JDI implementation correct?
        > I think that assigning a daemon status for those JDI threads would be
        sufficient
        > to resolve the problem.
        >
        > This feature negativaly affects running of JDI tests from testbase_nsk.
        > Obviously, all JDI tests invoke System.exit() at the end to set the proper
        > exit code. However, if an uncought exception is thrown, the main thread of the
        > test is interrupted without invoking System.exit(). If an exception is thrown
        > after the test had launched debuggee, test never exits.
        >
        > Anyway, the test will be killed by Tonga after TONGA_TIMEOUT exceeds, but this
        > prevents the tests from the normal behaviour and diagnostics. This can also
        > lead to keeping in memory unkilled debuggee process, which hold the system
        > resources (such as TCP/IP ports) and prevents all futher tests from
        successfull
        > execution. You may see such a mass failure of the tests with the diagnostics:
        >
        > "Unable to bind to the IOPipe port: port is busy"
        >
        > Resolving the described problem would allow the tests to exit in a more
        > correct way and free system resources.
        >
        > You can find the above mentioned simple JDI test in the attached archive
        > 'test.tgz'. Please see 'test.README' file to know how to run the test.
        >
        > Thanks.
        > I
        >
        >
        --------------------------------------------------------------------------------
        > Name: test.tgz
        > test.tgz Type: Application/X-sun-default
        > Description: test.tgz

        --

        ------------- End Forwarded Message -------------


        ======================================================================

              tbell Tim Bell
              tbell Tim Bell
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: