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. ------------- Commit messages: - Fix comment typo. - Do a vm.resume() in case a stray ThreadDeathEvent comes in. Changes: https://git.openjdk.java.net/jdk/pull/8003/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8003&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283717 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8003.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8003/head:pull/8003 PR: https://git.openjdk.java.net/jdk/pull/8003
