On Fri, 2 Jun 2023 21:47:47 GMT, Chris Plummer <[email protected]> wrote:
> JdbMethodExitTest.java tries to determine the jdb threadID for the "main"
> thread, and then later use it in jdb commands that require a threadID. It
> does this by first having the debuggee execute the following:
>
> System.out.println("threadid="+Thread.currentThread().getId());
>
> And then later on the test parses the threadID from this output. The problem
> is that the id returned by getId() has no relation to threadIDs used by jdb,
> which are actually JDWP ObjectIDs. In the past this has worked due to some
> dumb luck. getID() always returns 1 for the main thread, which is always the
> thread we are executing in. Coincidentally the JDWP ObjectID for the main
> Thread object is also always 1 because this is the first ObjectID that the
> debug agent ever needs to create. However, when the debuggee main thread is a
> virtual thread, neither getId() nor JDWP assign 1 to the threadID, and in
> fact both will end up with very different values for the threadID. The end
> result is errors from jdb for using an invalid threadID.
>
> The correct threadID can be obtained by executing the jdb "threads" command
> and parsing it from a line that looks like the following:
>
> (java.lang.VirtualThread)694 main running (at breakpoint)
>
> Note this test will also fail due to
> [JDK-8309334](https://bugs.openjdk.org/browse/JDK-8309334) and
> [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which should be
> fixed first.
>
> I've tested with mach5 tier5 in a workspace that has integrated the various
> CRs mentioned. Once JDK-8309334 and JDK-8309397 are fixed, before integrating
> this PR I'll first merge and verify that the test being removed from the
> problem list by this PR also passes.
Marked as reviewed by amenkov (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/14294#pullrequestreview-1458578358
