On Mon, 28 Mar 2022 19:58:59 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
> In this test the debuggee creates a couple of threads, and the debugger > checks to make sure it gets a ThreadStartEvent for each of these threads, > plus one for the main debuggee thread. Once it has done this, it disables the > ThreadStartRequest and sends a "quit" command to the debuggee. However, > another ThreadStartEvent can arrive after the expected 3, and this will cause > all debuggee threads to be suspended (since the ThreadStartRequest uses the > SUSPEND_ALL). If this happens the debuggee cannot even read "quit" message > and terminate, so the debugger times out waiting. The solution is to simply > to an unconditional vm.resume() after disabling ThreadStartRequest. > > Note this bug was observed in loom due to the creation of carrier threads, > but it could potentially happen in jdk also since the jvm creates numerous > threads on startup, and they can potentially be delayed a bit. Thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/8003
