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. This pull request has now been integrated. Changeset: f9f439a1 Author: Chris Plummer <cjplum...@openjdk.org> URL: https://git.openjdk.java.net/jdk/commit/f9f439a19d11501cfa77db065051086ab794e9f4 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8283717: vmTestbase/nsk/jdi/ThreadStartEvent/thread/thread001 failed due to SocketTimeoutException Reviewed-by: lmesnik, amenkov, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/8003
