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