RFR: 8283717: vmTestbase/nsk/jdi/ThreadStartEvent/thread/thread001 failed due to SocketTimeoutException
Chris Plummer
cjplummer at openjdk.java.net
Mon Mar 28 20:05:51 UTC 2022
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
More information about the serviceability-dev
mailing list