On Wed, 1 Jul 2026 23:00:55 GMT, Chris Plummer <[email protected]> wrote:
> The test creates and enables about 10 ThreadStartRequests. It does not expect > there to be any threads created while these requests are active. It simply > creates them to test out some ThreadStartRequest bookkeeping APIs. However, > VirtualThreads introduces spurious creation of ForkJoinPool-1-worker threads. > When the test eventually calls EventQueue.remove() to get the next event, it > expects a BreakpointEvent. But now it sometimes gets a ThreadStartEvent. This > was fixed in JDIBase.breakpointForCommunication() by filtering out > ThreadStartRequests. However, that was done to fix other tests that create > ThreadStartRequests, not this one. What is different about this test is that > the ThreadStartRequests use SUSPEND_ALL rather then SUSPEND_NONE. So it is > not enough to just skip the ThreadStartEvent. eventSet.resume() needs to be > called to resume all the threads, including the one that the breakpoint is > set on (which may or may not have triggered). The end result of this bug is > that the thread the breakpoint happens on remains suspended, so the BreakpointEvent is never sent and the test times out. Calling eventSet.resume() seems to fix the issue. > > Tested by running the test with virtual threads at least 1000 times (it was > reproducing much more often than this). Ran all nsk/jdk tests about 200 > times. Ran all svc tier2 and tier5 tests. > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). Sounds reasonable. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/31746#pullrequestreview-4614976286
