Skip to content

cmd/go: panic when building a main package in GOPATH mode when a go.work file exists #58767

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.

Sign up for GitHub

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

Jump to bottom
Closed
dr2chase opened this issue Feb 27, 2023 · 6 comments
Closed

cmd/go: panic when building a main package in GOPATH mode when a go.work file exists #58767

dr2chase opened this issue Feb 27, 2023 · 6 comments
Assignees
@bcmills
Labels
FrozenDueToAge GoCommand cmd/go NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.21

Comments

@dr2chase
Copy link
Contributor

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

go version devel go1.21-fcfbbf2ff6 Mon Feb 27 15:31:13 2023 +0000 darwin/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
go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/drchase/Library/Caches/go-build"
GOENV="/Users/drchase/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/drchase/work/src/fflags/p/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH=""
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/drchase/work/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/drchase/work/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="devel go1.21-fcfbbf2ff6 Mon Feb 27 15:31:13 2023 +0000"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/v6/9yfw749x623dr55rpm6ntnsc0095tn/T/go-build2046894004=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

./make.bash
# be sure freshly build go is on my path
cd cmd/go
go test .

What did you expect to see?

success

What did you see instead?

many failures, all sharing (some fraction of) the stack trace

            	panic: runtime error: invalid memory address or nil pointer dereference
            [signal SIGSEGV: segmentation violation code=0x1 addr=0x60 pc=0x148e3be]

            goroutine 1 [running]:
            cmd/go/internal/load.(*preload).flush(0xc00008fb90)
            	/Users/drchase/work/go/src/cmd/go/internal/load/pkg.go:1090 +0x74
            panic({0x16aa4c0?, 0x1c34b70?})
            	/Users/drchase/work/go/src/runtime/panic.go:912 +0x21f
            cmd/go/internal/modload.(*MainModuleSet).GoVersion(0x1c66620?)
            	/Users/drchase/work/go/src/cmd/go/internal/modload/init.go:226 +0x9e
            cmd/go/internal/load.defaultGODEBUG(0xc0001b8600, {0x0, 0x0, 0x0}, {0x0, 0x0, 0x0}, {0x0, 0x0, 0x0})
            	/Users/drchase/work/go/src/cmd/go/internal/load/godebug.go:56 +0x8c
            cmd/go/internal/load.(*Package).load(0xc0001b8600, {0x1881930, 0x1c7d398}, {0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0}, ...)
            	/Users/drchase/work/go/src/cmd/go/internal/load/pkg.go:1923 +0x13c8
            cmd/go/internal/load.loadImport({0x1881930, 0x1c7d398}, {0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0}, 0xc00008fb90, ...)
            	/Users/drchase/work/go/src/cmd/go/internal/load/pkg.go:750 +0x512
            cmd/go/internal/load.PackagesAndErrors({0x1881930?, 0x1c7d398?}, {0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0}, {0xc0000a8070, ...})
            	/Users/drchase/work/go/src/cmd/go/internal/load/pkg.go:2846 +0x9e5
            cmd/go/internal/list.runList({0x1881930?, 0x1c7d398}, 0xc0000b8408?, {0xc0000a8070?, 0x0, 0x0})
            	/Users/drchase/work/go/src/cmd/go/internal/list/list.go:610 +0xd67

I tried to debug this by reproducing the actions for TestFFLAGS but could not figure out the right way to run the command, so was unable. I wanted this failure:

    go_test.go:2061: running testgo [build -x p]
    go_test.go:2061: standard error:
    go_test.go:2061: WORK=/var/folders/v6/9yfw749x623dr55rpm6ntnsc0095tn/T/cmd-go-test-1037735542/go-build3705159710
        panic: runtime error: invalid memory address or nil pointer dereference [recovered]
        	panic: runtime error: invalid memory address or nil pointer dereference
        [signal SIGSEGV: segmentation violation code=0x1 addr=0x60 pc=0x148e3be]

        goroutine 1 [running]:
        cmd/go/internal/load.(*preload).flush(0xc000191980)
        	/Users/drchase/work/go/src/cmd/go/internal/load/pkg.go:1090 +0x74
        panic({0x16aa4c0?, 0x1c34b70?})
        	/Users/drchase/work/go/src/runtime/panic.go:912 +0x21f
        cmd/go/internal/modload.(*MainModuleSet).GoVersion(0x0?)
        	/Users/drchase/work/go/src/cmd/go/internal/modload/init.go:226 +0x9e
        cmd/go/internal/load.defaultGODEBUG(0xc000230600, {0x0, 0x0, 0x0}, {0x0, 0x0, 0x0}, {0x0, 0x0, 0x0})
        	/Users/drchase/work/go/src/cmd/go/internal/load/godebug.go:56 +0x8c
        cmd/go/internal/load.(*Package).load(0xc000230600, {0x1881930, 0x1c7d398}, {0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0}, ...)
        	/Users/drchase/work/go/src/cmd/go/internal/load/pkg.go:1923 +0x13c8
        cmd/go/internal/load.loadImport({0x1881930, 0x1c7d398}, {0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0}, 0xc000191980, ...)
        	/Users/drchase/work/go/src/cmd/go/internal/load/pkg.go:750 +0x512
        cmd/go/internal/load.PackagesAndErrors({0x1881930?, 0x1c7d398?}, {0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0}, {0xc00018e070, ...})
        	/Users/drchase/work/go/src/cmd/go/internal/load/pkg.go:2846 +0x9e5
        cmd/go/internal/work.runBuild({0x1881930, 0x1c7d398}, 0xc0001a6408?, {0xc00018e070, 0x1, 0x1})
        	/Users/drchase/work/go/src/cmd/go/internal/work/build.go:457 +0xfb
        cmd/go.invoke(0x1c40860, {0xc00018e050, 0x3, 0x3})
        	/Users/drchase/work/go/src/cmd/go/main.go:225 +0x3c3
        cmd/go.main()
        	/Users/drchase/work/go/src/cmd/go/main.go:179 +0x7d1
        cmd/go.Main(...)
        	/Users/drchase/work/go/src/cmd/go/export_test.go:7
        cmd/go_test.TestMain(0xc00006c730?)
        	/Users/drchase/work/go/src/cmd/go/go_test.go:154 +0x1425
        main.main()
        	_testmain.go:191 +0x1c6

but because I could not figure out the exact environment for running go (the test claimed to be running "testgo"), instead I saw

package p is not in GOROOT (/Users/drchase/work/go/src/p)

When I guessed at a way to run the command (cd ~/work/src/fflags/p/src/p; go build main.go -- no idea if this is what the test harness was doing or not) I got the successful expected failure

command-line-arguments: invalid flag in #cgo FFLAGS: -no-such-fortran-flag

but I have no idea what's actually going on here, I am just guessing. Darn shame the test was not more explicit about the details of what it was trying to do.
@bcmills
Copy link
Contributor

bcmills commented Feb 27, 2023

The stack trace in the failure shows

            	/Users/drchase/work/go/src/cmd/go/internal/modload/init.go:226 +0x9e

(https://cs.opensource.google/go/go/+/fcfbbf2ff68a8997438d82cc2800c4744e908854:src/cmd/go/internal/modload/init.go;l=226).

That suggests that inWorkspaceMode() is true but mms is nil — but inWorkspaceMode() would imply a non-empty GOWORK variable in the go env output. 🤔

@dr2chase
Copy link
Contributor Author

Additional information: I modified the test to print out working directories and environments, then started pruning the environment, and eventually discovered that the failure was sensitive to the directory. If I ran the command in $GOROOT/src (note that this directory contains go.work, see above comment) then it fails with a panic, otherwise it fails with the expected complain about fortran flags:

HOME=/test-go-home-does-not-exist TMPDIR=/tmp/foo USER=drchase  \
PATH=/Users/drchase/work/go-quick/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/Library/Apple/usr/bin \
PWD=/Users/drchase/work/go-quick/src/cmd/go GOVCS='*:all' \
CMDGO_TEST_RUN_MAIN=true TESTGO_GOROOT=/Users/drchase/work/go-quick \
GOROOT=/Users/drchase/work/go-quick TESTGO_GOHOSTOS=darwin \
TESTGO_GOHOSTARCH=amd64 GOENV=off CCACHE_DISABLE=1 \
GOCACHE=/Users/drchase/Library/Caches/go-build GO111MODULE=off \
GOPATH=/Users/drchase/work/src/fflags/p go build -x p

Contents of $GOPATH in that command:

Contents (src subdirectory) of $GOPATH for FFLAGS test.
-- src/p/a.f --
! comment
-- src/p/main.go --
package main

// #cgo FFLAGS: -no-such-fortran-flag
import "C"

func main() {}

So, that is the workaround, presence of go.work is suspected to be the trigger.
Removing go.work is correlated with the bug going away.

At minimum, the test ought to detect this and fail in a more informative way.

@dr2chase
Copy link
Contributor Author

Turns out I typed "go env" in a different directory than the one where it was crashing, which explains the missing GOWORK variable.

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/471600 mentions this issue: cmd/go: disable workspace mode in GOPATH mode

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/471601 mentions this issue: cmd/go: set GOWORK=off explicitly in script tests that cd to GOROOT

@dmitshur dmitshur added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. GoCommand cmd/go labels Feb 27, 2023
@dmitshur dmitshur added this to the Backlog milestone Feb 27, 2023
@bcmills bcmills self-assigned this Feb 28, 2023
@bcmills bcmills changed the title cmd/go: "go test ." fails a lot without providing enough information to debug the failure cmd/go: tests fail when GOROOT/src contains a go.work file Feb 28, 2023
@bcmills bcmills added the NeedsFix The path to resolution is known, but the work has not been done. label Feb 28, 2023
@bcmills bcmills modified the milestones: Backlog, Go1.21 Feb 28, 2023
@gopherbot gopherbot removed the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 28, 2023
@bcmills bcmills changed the title cmd/go: tests fail when GOROOT/src contains a go.work file cmd/go: panic when building a main package in GOPATH mode when a go.work file exists Feb 28, 2023
gopherbot pushed a commit that referenced this issue Feb 28, 2023
@gopherbot
cmd/go: disable workspace mode in GOPATH mode
af75817 
Workspace mode is specifically for working with modules;
it doesn't make sense in GOPATH mode.

This also fixes a panic in (*modload.MainModuleSet).GoVersion
when go.work is present in GOPATH mode.

For #58767.

Change-Id: Ic6924352afb486fecc18e009e6b517f078e81094
Reviewed-on: https://go-review.googlesource.com/c/go/+/471600
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
gopherbot pushed a commit that referenced this issue Feb 28, 2023
@gopherbot
cmd/go: set GOWORK=off explicitly in script tests that cd to GOROOT
454198a 
Some folks working on the Go project may have a go.work file in
GOROOT/src in order to test changes in x repos. 'go test cmd/go'
should not fail if that is the case.

For #58767.

Change-Id: I0e57b15fb1d3e4abc4903c177434626c9f125cae
Reviewed-on: https://go-review.googlesource.com/c/go/+/471601
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: David Chase <drchase@google.com>
@bcmills
Copy link
Contributor

bcmills commented Feb 28, 2023

I believe this is now fixed, but please let me know if you're still seeing failures.

@bcmills bcmills closed this as completed Feb 28, 2023
@golang golang locked and limited conversation to collaborators Feb 28, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@bcmills bcmills

Labels
FrozenDueToAge GoCommand cmd/go NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.21
Development

No branches or pull requests
4 participants
@dmitshur @dr2chase @bcmills @gopherbot