go: runtime: `TestCtrlHandler` fails when run manually on a `windows-amd64-2016` gomote

What version of Go are you using (go version)?

A clean build from source at commit 914195c132cbec651aa43c409e8aac2614b53b38 on a windows-amd64-2016 gomote.

Does this issue reproduce with the latest release?

I have no reason to believe otherwise.

What operating system and processor architecture are you using (go env)?

go env Output
gopher@SERVER-2016-V7- C:\workdir\go\src>..\bin\go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\gopher\AppData\Local\go-build
set GOENV=C:\Users\gopher\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\gopher\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\gopher\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\workdir\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\workdir\go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=devel gomote.XXXXX
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\workdir\go\src\go.mod
set GOWORK=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\gopher\AppData\Local\Te
mp\go-build1381519030=/tmp/go-build -gno-record-gcc-switches

What did you do?

gopher@SERVER-2016-V7- C:\workdir\go\src>set PATH=%PATH%;C:\godep\gcc64\bin

gopher@SERVER-2016-V7- C:\workdir\go\src>set GOROOT_BOOTSTRAP=C:\workdir\go1.4

gopher@SERVER-2016-V7- C:\workdir\go\src>make.bat
Building Go cmd/dist using C:\workdir\go1.4
Building Go toolchain1 using C:\workdir\go1.4.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for windows/amd64.
---
Installed Go for windows/amd64 in C:\workdir\go
Installed commands in C:\workdir\go\bin

gopher@SERVER-2016-V7- C:\workdir\go\src>..\bin\go version
go version devel gomote.XXXXX windows/amd64

gopher@SERVER-2016-V7- C:\workdir\go\src>..\bin\go test runtime -run=TestCtrlHandler

What did you expect to see?

The test should either pass or skip itself.

What did you see instead?

--- FAIL: TestCtrlHandler (0.56s)
    signal_windows_test.go:125: failed to kill: exit status 1
FAIL
FAIL    runtime 0.589s
FAIL

The test also fails in the same way when run by dist test:

gopher@SERVER-2016-V7- C:\workdir\go\src>..\bin\go tool dist test go_test:runtime

##### Test execution environment.
# GOARCH: amd64
# CPU: Intel(R) Xeon(R) CPU @ 2.20GHz
# GOOS: windows
# OS Version: 10.0.14393

##### Testing packages.
--- FAIL: TestCtrlHandler (0.98s)
    signal_windows_test.go:125: failed to kill: exit status 1
FAIL
FAIL    runtime 53.691s
FAIL
go tool dist: Failed: exit status 1

I updated the test to log the output from the failing taskkill.exe invocation, and saw:

--- FAIL: TestCtrlHandler (0.51s)
    signal_windows_test.go:126: C:\Windows\system32\taskkill.exe /pid 1508: exit status 1
        ERROR: The process with PID 1508 could not be terminated.
        Reason: This process can only be terminated forcefully (with /F option).

This test was added in CL 261057 for #41884 (CC @ncruce @alexbrainman @zx2c). For some reason it is not failing on the windows-amd64-longtest builder, but the gomote environment is substantially different from the environment actually used by the buildlet (see #32430).

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 16 (14 by maintainers)

Most upvoted comments

The bot is badly backlogged. I’ll keep an eye on it and send the TryBots for another spin on the Gerrit CL once it’s back.

I added some commits to #51681, but @gopherbot doesn’t seem to be picking them up.

@bcmills I have an alternative fix that allows the test to run under SSH. Can you verify with gomote?

I can make any necessary fixes, including adding the timeout from https://go.dev/cl/391799

@alexbrainman, I don’t know of any way for the test to determine that it’s running under a gomote, and even if there were that’s not necessarily the only circumstance in which it would be connected to a pseudo-console (which it seems to me is the real condition we want to check for).