Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/link: binary failed to execute with "This version of %1 is not compatible with the version of Windows you're running." #44817

Open
bcmills opened this issue Mar 5, 2021 · 20 comments
Labels
NeedsInvestigation OS-Windows
Milestone

Comments

@bcmills
Copy link
Member

@bcmills bcmills commented Mar 5, 2021

2021-03-05T06:15:22-60b500d/windows-amd64-race

CC @alexbrainman @zx2c4 @jeremyfaller

@bcmills bcmills added OS-Windows NeedsInvestigation labels Mar 5, 2021
@bcmills bcmills added this to the Backlog milestone Mar 5, 2021
@bcmills bcmills changed the title cmd/compile,cmd/link: binary fails to execute with "This version of %1 is not compatible with the version of Windows you're running." cmd/compile,cmd/link: binary failed to execute with "This version of %1 is not compatible with the version of Windows you're running." Mar 5, 2021
@bcmills
Copy link
Member Author

@bcmills bcmills commented Mar 5, 2021

Very likely related to #34774.

@zx2c4
Copy link
Contributor

@zx2c4 zx2c4 commented Mar 5, 2021

Is this a rare bug or is it happening all the time?

@bcmills
Copy link
Member Author

@bcmills bcmills commented Mar 5, 2021

Very rare.

@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Mar 5, 2021

I don't have time even to look at the code. But the error message is, probably, because of executable is corrupted.

Alex

@bcmills
Copy link
Member Author

@bcmills bcmills commented Apr 22, 2021

@bcmills
Copy link
Member Author

@bcmills bcmills commented May 16, 2022

This seems to reproduce most often (but not exclusively) when running cmd/go.TestWindowsDefaultBuildmodIsPIE/cgo.

--- FAIL: TestWindowsDefaultBuildmodIsPIE (0.00s)
    --- FAIL: TestWindowsDefaultBuildmodIsPIE/cgo (2.98s)
        go_test.go:2197: running testgo [build -o C:\Users\gopher\AppData\Local\Temp\1\cmd-go-test-3173413636\gotest3609786383\main.exe C:\Users\gopher\AppData\Local\Temp\1\cmd-go-test-3173413636\gotest3609786383\main.go]
        go_test.go:2286: fork/exec C:\Users\gopher\AppData\Local\Temp\1\cmd-go-test-3173413636\gotest3609786383\main.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.
go test proxy running at GOPROXY=http://127.0.0.1:51709/mod
FAIL
FAIL	cmd/go	174.990s

greplogs -l -e 'not compatible with the version of Windows' --since=2022-05-11
2022-05-13T19:45:43-ba8310c/windows-amd64-race

@bcmills
Copy link
Member Author

@bcmills bcmills commented May 16, 2022

(CC @randall77 @griesemer for cmd/compile, @cherrymui @rsc @ianlancetaylor for cmd/link. It isn't clear to me which binary is producing the corrupted parts of the executable.)

@randall77
Copy link
Contributor

@randall77 randall77 commented May 16, 2022

It's almost certainly the linker (or, perhaps, the host linker, because cgo?). If the compiler generated garbage instructions, say, it wouldn't make this kind of error. It would just be a SIGILL when running.
Maybe the linker needs some extra flush somewhere?

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented May 16, 2022

Several cases are failing when running the (newly created) linker.

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.
go tool link: fork/exec C:\workdir\go\pkg\tool\windows_amd64\link.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.

All cases are failing to run a newly created binary.

I have a vague recollection that we've had trouble in the past running a newly created executable on Windows, but I couldn't pin it down.

I wonder if it would be appropriate for cmd/link to call FlushFileBuffers in OutBuf.munmap in cmd/link/internal/ld/outbuf_windows.go. CC @cherrymui @thanm

@thanm
Copy link
Contributor

@thanm thanm commented May 17, 2022

I wonder if it would be appropriate for cmd/link to call FlushFileBuffers in OutBuf.munmap

Seems like a promising idea. Testing such a change seems tricky given the infrequency of the problem.

Documentation for FlushFileBuffers says:

... The caller must have administrative privileges. ... https://docs.microsoft.com/en-us/windows/win32/secbp/running-with-special-privileges

Not sure if we can guarantee that?

In any case, I can give it a try.

@thanm
Copy link
Contributor

@thanm thanm commented May 17, 2022

I wrote a CL to do this at https://go-review.googlesource.com/c/go/+/406814 , but it doesn't seem to work (I must be holding something wrong). Fails bootstrap on windows with

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.
C:\workdir\go\pkg\tool\windows_amd64\link: FlushFileBuffers failed: The handle is invalid.

If anyone can see where I went wrong, let me know.

@cherrymui
Copy link
Member

@cherrymui cherrymui commented May 17, 2022

Issue #38440 is a previous issue about newly created executables and file mappings on Windows. I added FlushViewOfFile for that. Maybe it is not enough?

@cherrymui
Copy link
Member

@cherrymui cherrymui commented May 17, 2022

@thanm I think FlushFileBuffers takes a file handle, not a file mapping handle. Perhaps syscall.Handle(out.f.Fd()) is the one we want.

@thanm
Copy link
Contributor

@thanm thanm commented May 17, 2022

Thanks, I suspected it was something like that. I'll try your suggestion.

@gopherbot
Copy link

@gopherbot gopherbot commented May 18, 2022

Change https://go.dev/cl/406814 mentions this issue: cmd/link: call syscall.FlushFileBuffers on outbuf Unmap

@bcmills bcmills changed the title cmd/compile,cmd/link: binary failed to execute with "This version of %1 is not compatible with the version of Windows you're running." cmd/link: binary failed to execute with "This version of %1 is not compatible with the version of Windows you're running." May 25, 2022
@bcmills
Copy link
Member Author

@bcmills bcmills commented May 25, 2022

One more today. (Is CL 406814 still waiting on a gomote swarm?)

greplogs -l -e 'not compatible with the version of Windows' --since=2022-05-14
2022-05-24T21:25:09-b6bcd0d/windows-amd64-longtest

##### ../misc/reboot
Building Go cmd/dist using C:\workdir\go
Building Go toolchain1 using C:\workdir\go.
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.
go tool link: fork/exec C:\Users\gopher\AppData\Local\Temp\1\TestRepeatBootstrap2327678893\001\pkg\tool\windows_amd64\link.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.

go tool dist: FAILED: C:\Users\gopher\AppData\Local\Temp\1\TestRepeatBootstrap2327678893\001\pkg\tool\windows_amd64\go_bootstrap list -f={{if .Stale}}	STALE {{.ImportPath}}: {{.StaleReason}}{{end}} cmd/asm cmd/cgo cmd/compile cmd/link runtime/internal/sys: exit status 1
--- FAIL: TestRepeatBootstrap (85.00s)
    reboot_test.go:30: GOROOT/src overlay set up in 1.0830123s
    reboot_test.go:52: exit status 1
FAIL

@thanm
Copy link
Contributor

@thanm thanm commented May 31, 2022

Swarm running last week generated a bunch of failures (mostly TestCallbackInAnotherThread) but nothing that matched this problem.

Consensus seems to be that submitting CL 406814 would be a positive step, so I will go ahead and check in the CL but leave this issue open.

gopherbot pushed a commit that referenced this issue May 31, 2022
In the windows version of OutBuf.munmap, call syscall.FlushFileBuffers
after the call to syscall.FlushViewOfFile, on the theory that this
will help flush all associated meta-data for the file the linker is
writing.

Updates #44817.

Change-Id: Ibff7d05008a91eeed7634d2760153851e15e1c18
Reviewed-on: https://go-review.googlesource.com/c/go/+/406814
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
@thanm
Copy link
Contributor

@thanm thanm commented Jun 14, 2022

No new failures so far after CL 406814 ... of course it has only been a couple of weeks. Probably best to leave open for a few more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation OS-Windows
Projects
None yet
Development

No branches or pull requests

8 participants