-
Bug
-
Resolution: Fixed
-
P3
-
1.4.0
-
hopper
-
generic
-
generic
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2048004 | 1.4.0 | Tim Bell | P3 | Closed | Fixed | rc1 |
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 -------------
======================================================================
- backported by
-
JDK-2048004 JDI: Internal JDI helper threads should setDaemon(true)
-
- Closed
-