cmd/go,runtime: `runtime.GOROOT` returns an invalid, non-empty string when built with -trimpath

[rittneje]

Reopening #51409 because I don't think "it's a counterfeiter bug" is a sufficient explanation. How can counterfeiter (or any application) cause the go tool to lose track of the implied GOROOT?

What version of Go are you using (go version)?

$ go version
go version go1.17.7 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE="auto"
GOARCH="amd64"
GOBIN=""
GOCACHE="/tmp/.gocache"
GOENV="/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/Users/rittneje/test/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/Users/rittneje/test"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.7"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="0"
GOMOD="/Users/rittneje/test/src/gorootbug/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1092411943=/tmp/go-build -gno-record-gcc-switches"

Note that the GOROOT environment variable is not set. (It is being calculated automatically from the go command's location.)

What did you do?

package gorootbug

//go:generate /usr/local/gotools/bin/counterfeiter io.Reader

Then ran go generate.

What did you expect to see?

It should work.

What did you see instead?

$ go generate -x
/usr/local/gotools/bin/counterfeiter io.Reader
Writing `FakeReader` to `gorootbugfakes/fake_reader.go`... 
go/build: go list io: exit status 2
go: cannot find GOROOT directory: go


bug.go:3: running "/usr/local/gotools/bin/counterfeiter": exit status 1

If I explicitly set GOROOT to itself, then it works.

$ GOROOT=$(go env GOROOT) go generate -x
/usr/local/gotools/bin/counterfeiter io.Reader
Writing `FakeReader` to `gorootbugfakes/fake_reader.go`... Done

[bcmills]

How can counterfeiter (or any application) cause the go tool to lose track of the implied GOROOT?

Most likely? If it explicitly sets a non-empty GOROOT variable in the process environment to a non-directory or a nonexistent directory, then cmd/go won't override that explicit value with the implicit one.

[bcmills]

Sorry, but this really doesn't look like a cmd/go bug from the information we have so far. If you can get counterfeiter to dump the subprocess's environment, maybe we can investigate from there.

[seankhliao]

where did you obtain the go binary from?

[rittneje]

@seankhliao @bcmills I have tracked this issue down to a bug in Go. When you pass -trimpath to go build (or similar), it corrupts runtime.GOROOT() in the resulting binary.

package main

import (
	"fmt"
	"runtime"
)

func main() {
	fmt.Println(runtime.GOROOT())
}

With go run, it prints /usr/local/go as expected. With go run -trimpath, it incorrectly prints go.

[ianlancetaylor]

It has always worked that way, but it does seem problematic.

[rittneje]

@ianlancetaylor One thing I do want to point out is that for this specific use case, the issue actually manifests itself within the go/build package, specifically here:

go/src/go/build/build.go

Line 1185 in 81767e2

"GOROOT="+ctxt.GOROOT,

In the case of build.Default, it would make more sense not to bother setting GOROOT at all, rather than trying to override it. Then when it invokes the go list command, it'll just figure out GOROOT as usual, which will work regardless of whether -trimpath was applied to the binary that is using build.Default, or even if the binary was compiled on another machine with a totally different GOROOT. In fact, it seems like runtime.GOROOT() is not useful in general, and robust applications ought to use go env GOROOT instead.

I created a separate issue (#51473) to discuss deprecating runtime.GOROOT().

[bcmills]

At the very least, runtime.GOROOT() should probably return the empty string instead of an invalid path when the binary is built with -trimpath — that would make it much more obvious that the value isn't actually “the root used during the Go build” as documented.

[bcmills]

for this specific use case, the issue actually manifests itself within the go/build package

Thanks, that's helpful and straightforward to reproduce. Filed separately as #51483.