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)
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).