cmd/link/internal/ld: TestRuntimeTypeAttrInternal flaky on Windows

[bcmills]

#!watchflakes
post <- pkg == "cmd/link/internal/ld" && `This version of %1 is not compatible`

Seen on the windows-amd64-2016 builder in https://storage.googleapis.com/go-build-log/4a655811/windows-amd64-2016_5d978c1a.log:

--- FAIL: TestRuntimeTypeAttrInternal (0.73s)
    dwarf_test.go:973: could not run test program: fork/exec C:\Users\gopher\AppData\Local\Temp\1\TestRuntimeType696325427\out.exe: This version of %1 is not compatible with the version of Windows you're running. Check your computer's system information and then contact the software publisher.
FAIL
FAIL	cmd/link/internal/ld	3.767s

CC @cherrymui @jeremyfaller

[bcmills]

2019-11-20T17:13:59-b89b462/windows-amd64-longtest
2019-02-26T18:37:19-01971b9/windows-amd64-2016

[jeremyfaller]

Is this a flaky, or repeated? Judging from it's infrequency occurrence, it looks a flaky??

I can't see any new reason for this test to fail.

[bcmills]

Yes, it appears to be a flake, but it's happened enough times that it seems unlikely to be a hardware issue (cosmic ray or thermal jitter).

It's not obvious to me whether it's a bug in the test, a bug cmd/go, a bug in os/exec, or a bug in Windows.

[bcmills]

CC @alexbrainman @zx2c4

[alexbrainman]

Looking at testRuntimeTypeAttr source, I notice that you open file

f := gobuild(t, dir, prog, flags)

and then execute the file

... exec.Command(f.path).CombinedOutput()

I am surprised that Windows allows you to execute opened file.

Perhaps unrelated, but I also noticed that file f is never closed. Why?

Alex

[neurlang]

Hello, I can reproduce this issue every time on windows 11. Go is 1.20.6

Folder structure

cmd/main.go

Bug example main.go:

package cmd
func main() {
}

CreateProcess error=216, This version of %1 is not compatible with the version of Windows you're running. Check your computer's system information and then contact the software publisher

Working example main.go:

package main
func main() {
}

Thanks.

[bcmills]

@neurlang, thanks, that's a good lead but I think we need more details to be able to reproduce. Specifically:

• What version on Windows 11 are you using?
• Please post the output of go env so that we can check architecture details (amd64 vs. arm64, architecture settings, GOFLAGS, etc.)
• If you have a C toolchain installed, what version is it? (Please post the output of gcc --version or similar, and ideally a link to the toolchain provider's download page.)

[bcmills]

Hmm. This issue is specific to TestRuntimeTypeAttrInternal; the more general failure mode is #44817.

@neurlang, could you post the details requested above to that issue?

[neurlang]

What version on Windows 11 are you using?

Windows 11 Pro, 22H2 , build 22621.2134

Please post the output of go env so that we can check architecture details (amd64 vs. arm64, architecture settings, GOFLAGS, etc.)

all flags are default, cpu is amd64

GOROOT=C:\Users\me\sdk\go1.20.6 #gosetup
GOPATH=C:\Users\me\go #gosetup
C:\Users\me\sdk\go1.20.6\bin\go.exe build -o C:\Users\me\AppData\Local\JetBrains\GoLand2023.2\tmp\GoLand___go_build_example_com_bug_cmd.exe . #gosetup
C:\Users\me\AppData\Local\JetBrains\GoLand2023.2\tmp\GoLand___go_build_example_com_bug_cmd.exe

If you have a C toolchain installed, what version is it? (Please post the output of gcc --version or similar, and ideally a link to the toolchain provider's download page.)

no gcc

[neurlang]

that project didnt use gcc, its empty program. Here is go env

$ ./go.exe env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\me\AppData\Local\go-build
set GOENV=C:\Users\me\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\me\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\me\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Users\me\sdk\go1.20.6
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Users\me\sdk\go1.20.6\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.20.6
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=0
set GOMOD=NUL
set GOWORK=
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=C:\Users\me\AppData\Local\Temp\go-build1016806918=/tmp/go-build -gno-record-gcc-switches

[bcmills]

And what was the exact command you used to build the Go program?

(If you built it using an IDE, please reproduce the failure on the command line so that we can be sure of what flags are passed to the go command.)

[neurlang]

now tested, can only reproduce it in the goland IDE. On the console, I haven't been able to reproduce it.

[bcmills]

Maybe there is some way the IDE can tell you what commands and/or environment it is invoking?

[MattBrittan]

now tested, can only reproduce it in the goland IDE. On the console, I haven't been able to reproduce it.

Can replicate this from the command line with go build -o temp3.exe then executing the created temp3.exe (using the package cmd version of the example code, so no expectation it would work!). I'd guess that GoLand attempts to run this in a similar way (but GoLand 2023.2.2 does pop up a warning the 'main' file has the non-main package..., followed by a second warning, before allowing you to continue and displaying the error). Probably means that this method of replicating the error is not linked is not linked to the failing test.