[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8283717: vmTestbase/nsk/jdi/ThreadStartEvent/thread/thread001 failed due to SocketTimeoutEx
From:       Chris Plummer <cjplummer () openjdk ! java ! net>
Date:       2022-03-29 18:40:50
Message-ID: r3Y_VVjvfog9wOsqFK7VemIaqGR22ePzNVNQ01aL3wM=.33d58e7a-6f14-46c8-8926-ee520a6e5cc8 () github ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]