cmd/go: skip updateBuildID on binaries we will run

On modern Unix systems it is basically impossible for a multithreaded program to open a binary for write, close it, and then fork+exec that same binary. So don't write the binary if we're going to fork+exec it. This fixes the ETXTBSY flakes. Fixes #22220. See also #22315. Change-Id: I6be4802fa174726ef2a93d5b2f09f708da897cdb Reviewed-on: https://go-review.googlesource.com/71570 Run-TryBot: Russ Cox <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]>
golang · Oct 19, 2017 · d790ea3 · d790ea3
1 parent 52dd399
commit d790ea3
Showing 1 changed file with 12 additions and 2 deletions.
diff --git a/src/cmd/go/internal/work/build.go b/src/cmd/go/internal/work/build.go
@@ -1696,8 +1696,18 @@ func (b *Builder) build(a *Action) (err error) {
  }
  }
 
- if err := b.updateBuildID(a, actionID, objpkg); err != nil {
- return err
+ // Update the binary with the final build ID.
+ // But if OmitDebug is set, don't, because we set OmitDebug
+ // on binaries that we are going to run and then delete.
+ // There's no point in doing work on such a binary.
+ // Worse, opening the binary for write here makes it
+ // essentially impossible to safely fork+exec due to a fundamental
+ // incompatibility between ETXTBSY and threads on modern Unix systems.
+ // See golang.org/issue/22220.
+ if !a.Package.Internal.OmitDebug {
+ if err := b.updateBuildID(a, actionID, objpkg); err != nil {
+ return err
+ }
  }
 
  return nil