-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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/go: 'go test -o' may fail with ETXTBSY
when running the compiled test
#62221
Comments
Found new dashboard test flakes for:
2023-08-04 16:02 linux-arm64-longtest go@55d08e50 cmd/go.TestScript (log)
2023-08-18 20:44 linux-amd64-longtest-race go@ce160863 cmd/go.TestScript (log)
2023-08-18 22:41 linux-amd64-longtest-race go@7af28fa9 cmd/go.TestScript (log)
|
Reproduced using:
It failed after a couple dozen iterations. |
My vote is to retry |
I agree with that assessment. |
Change https://go.dev/cl/522015 mentions this issue: |
@gopherbot, please backport to Go 1.21. This Go command bug causes occasional test failures in |
Backport issue(s) opened: #62222 (for 1.21). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases. |
Change https://go.dev/cl/522176 mentions this issue: |
An ETXTBSY error when starting a test binary is almost certainly caused by the race reported in golang#22315. That race will resolve quickly on its own, so we should just retry the command instead of reporting a spurious failure. Fixes golang#62221. Change-Id: I408f3eaa7ab5d7efbc7a2b1c8bea3dbc459fc794 Reviewed-on: https://go-review.googlesource.com/c/go/+/522015 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Bryan Mills <bcmills@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
…t binaries An ETXTBSY error when starting a test binary is almost certainly caused by the race reported in #22315. That race will resolve quickly on its own, so we should just retry the command instead of reporting a spurious failure. Fixes #62222. Updates #62221. Change-Id: I408f3eaa7ab5d7efbc7a2b1c8bea3dbc459fc794 Reviewed-on: https://go-review.googlesource.com/c/go/+/522015 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Bryan Mills <bcmills@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> (cherry picked from commit 4dc2564) Reviewed-on: https://go-review.googlesource.com/c/go/+/522176 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
(Pulled out from #58019 (comment).)
When
go test
is run with the-o
flag but not the-c
flag, it writes out the requested binary and thenexec
s that binary.Occasionally that races with calling
exec
on another test in the same run, which can cause the file descriptor to be (briefly) held open by a child process, leading to the failure mode described in #22315.This can occur any time
go test -o
is used to build and run multiple tests.I can think of three possible fixes:
syscall.ForkLock
when copying test binaries, blocking anexec
anywhere else in the command from proceeding concurrently.cmd/go
with some secret handshake?) to copy the file, preventing other subprocesses from ever seeing the file descriptor.ETXTBSY
errors when running the test binary.The text was updated successfully, but these errors were encountered: