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

List:       openjdk-serviceability-dev
Subject:    Integrated: 8283717: vmTestbase/nsk/jdi/ThreadStartEvent/thread/thread001 failed due to
From:       Chris Plummer <cjplummer () openjdk ! java ! net>
Date:       2022-03-29 18:40:50
Message-ID: Xbcom3yKpx4QDfxjnE6G6iir2WVc0lWsXylDkFE7QQo=.756cb474-a6db-49f0-9e44-259b554aa6bb () 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.

This pull request has now been integrated.

Changeset: f9f439a1
Author:    Chris Plummer <cjplummer@openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f9f439a19d11501cfa77db065051086ab794e9f4
                
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

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

Reviewed-by: lmesnik, amenkov, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/8003


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