RFR: 8283717: vmTestbase/nsk/jdi/ThreadStartEvent/thread/thread001 failed due to SocketTimeoutException

Chris Plummer cjplummer at openjdk.java.net
Tue Mar 29 18:40:50 UTC 2022


On Mon, 28 Mar 2022 19:58:59 GMT, Chris Plummer <cjplummer at 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


More information about the serviceability-dev mailing list