On Fri, 2 Jun 2023 21:41:32 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
> The com/sun/jdi/JdbXXX tests rely on the jdb "threads" command output to find > the main thread. If it is a virtual thread, it will not be included in the > "threads" output unless the debuggee is run with -Djdk.trackAllThreads, so we > need to make sure to include this option when launching the debuggee. The > following tests are impacted. > > com/sun/jdi/JdbMethodExitTest.java > com/sun/jdi/JdbStepTest.java > com/sun/jdi/JdbStopThreadTest.java > com/sun/jdi/JdbStopThreadidTest.java > > Note that all these tests also fail due to > [JDK-8309334](https://bugs.openjdk.org/browse/JDK-8309334), which needs to be > fixed first. Also JdbMethodExitTest.java will fail due to > [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which should be > fixed after this CR. > > I've tested with mach5 tier5 in a workspace that has integrated the various > CRs mentioned. Once JDK-8309334 is fixed, before integrating this PR I'll > first merge and verify that the 3 tests being removed from the problem list > by this PR also pass. Would it be possible to expand a bit on why jdk.trackAllThreads is needed? I would have expected jdb "threads" command to be sensitive to whether the debuggee is launched with the JDWP includevirtualthreads option but jdk.trackAllThreads isn't used by the JDWP agent, it is instead used to determine if virtual threads created directly with the Thread API show up in thread dumps or not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14293#issuecomment-1574736478
