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

Jump to bottom

cmd/go/internal/modload: SIGSEGV: segmentation violation #51589

Closed
10ne1 opened this issue Mar 10, 2022 · 5 comments
Closed

cmd/go/internal/modload: SIGSEGV: segmentation violation #51589

10ne1 opened this issue Mar 10, 2022 · 5 comments
Assignees
@bcmills
Labels
FrozenDueToAge modules NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.20

Comments

@10ne1
Copy link

10ne1 commented Mar 10, 2022 •
edited

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

go version go1.17.1 linux/amd64
and also
go version go1.17.8 linux/amd64

These versions are used within the ChromeOS SDK / chroot environment.

Does this issue reproduce with the latest release?

I only tried the latest v1.17 minor release. I did not test v1.18 which is not released yet.

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

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/adi/.cache/go-build"
GOENV="/home/adi/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/adi/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/adi/go"
GOPRIVATE=""
GOPROXY="file:///usr/lib/go/proxy/"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.1"
GCCGO="gccgo"
AR="ar"
CC="x86_64-pc-linux-gnu-clang"
CXX="x86_64-pc-linux-gnu-clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
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 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2529356632=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I'm migrating the ChromeOS SDK from GOPATH mode to modules mode, so I'm making all ebuilds install into a GOPROXY file:/// path from where go mod download fetches, then go mod tidy is run before the build cmd. It all works neatly except when trying to build the golint packages & module deps, go segfaults.

I know golint is abandoned and frozen, but we still need to use it for now in ChromeOS - we have TODO to replace it with something else, but I think that is irrelevant to this segfault.

What did you expect to see?

The error about the missing .mod file should be fine. The SIGSEGV is unexpected.

What did you see instead?

Here is the full output:

golang.org/x/lint imports
        golang.org/x/tools/go/gcexportdata imports
        golang.org/x/tools/go/internal/gcimporter tested by
        golang.org/x/tools/go/internal/gcimporter.test imports
        golang.org/x/tools/go/buildutil tested by
        golang.org/x/tools/go/buildutil.test imports
        golang.org/x/tools/go/packages/packagestest imports
        golang.org/x/tools/go/expect imports
        golang.org/x/mod/modfile: golang.org/x/tools@v0.1.9 requires
        golang.org/x/sys@v0.0.0-20220309133719-04245dca01da: reading file:///usr/lib/go/proxy/golang.org/x/sys/@v/v0.0.0-20220309133719-04245dca01da.mod: no such file or directory
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x7d3f2d]

goroutine 1 [running]:
cmd/go/internal/modload.(*loader).checkMultiplePaths(0xc00004c480)
        /usr/lib/go/src/cmd/go/internal/modload/load.go:1747 +0x2d
cmd/go/internal/modload.loadFromRoots({0xa726a0, 0xc000124000}, {{{0x0, 0x0}, 0xc0001b9ce0, 0x1, {0x0, 0x0}, 0x1, 0x1, ...}, ...})
        /usr/lib/go/src/cmd/go/internal/modload/load.go:1122 +0xd78
cmd/go/internal/modload.LoadPackages({0xa726a0, 0xc000124000}, {{0x0, 0x0}, 0xc0001b9ce0, 0x1, {0x0, 0x0}, 0x1, 0x1, ...}, ...)
        /usr/lib/go/src/cmd/go/internal/modload/load.go:329 +0x328
cmd/go/internal/modcmd.runTidy({0xa726a0, 0xc000124000}, 0xc000164318, {0xc000136030, 0x4, 0x35})
        /usr/lib/go/src/cmd/go/internal/modcmd/tidy.go:114 +0x1b7
main.invoke(0xd81680, {0xc000136020, 0x2, 0x2})
        /usr/lib/go/src/cmd/go/main.go:216 +0x2f6
main.main()
        /usr/lib/go/src/cmd/go/main.go:173 +0x78e

Please ask if you need any help or more testing. Thank you!
@10ne1
Copy link
Author

10ne1 commented Mar 10, 2022

Here is another log, a bit longer from testify instead of golint:

go: gopkg.in/yaml.v3@v3.0.0-20220309205602-496545a6307b requires
        github.com/kr/text@v0.2.0 requires
        golang.org/x/sys@v0.0.0-20220309202614-04245dca01da: reading file:///usr/lib/go/proxy/golang.org/x/sys/@v/v0.0.0-20220309202614-04245dca01da.mod: no such file or directory
go: gopkg.in/yaml.v3@v3.0.0-20220309205602-496545a6307b requires
        github.com/kr/text@v0.2.0 requires
        golang.org/x/sys@v0.0.0-20220309202614-04245dca01da: reading file:///usr/lib/go/proxy/golang.org/x/sys/@v/v0.0.0-20220309202614-04245dca01da.mod: no such file or directory
go: gopkg.in/yaml.v3@v3.0.0-20220309205602-496545a6307b requires
        github.com/kr/text@v0.2.0 requires
        golang.org/x/sys@v0.0.0-20220309202614-04245dca01da: reading file:///usr/lib/go/proxy/golang.org/x/sys/@v/v0.0.0-20220309202614-04245dca01da.mod: no such file or directory
github.com/stretchr/testify/assert imports
        github.com/davecgh/go-spew/spew tested by
        github.com/davecgh/go-spew/spew.test imports
        github.com/davecgh/go-spew/spew/testdata: gopkg.in/yaml.v3@v3.0.0-20220309205602-496545a6307b requires
        github.com/kr/text@v0.2.0 requires
        golang.org/x/sys@v0.0.0-20220309202614-04245dca01da: reading file:///usr/lib/go/proxy/golang.org/x/sys/@v/v0.0.0-20220309202614-04245dca01da.mod: no such file or directory
github.com/stretchr/testify/assert imports
        gopkg.in/yaml.v3 tested by
        gopkg.in/yaml.v3.test imports
        gopkg.in/check.v1: gopkg.in/yaml.v3@v3.0.0-20220309205602-496545a6307b requires
        github.com/kr/text@v0.2.0 requires
        golang.org/x/sys@v0.0.0-20220309202614-04245dca01da: reading file:///usr/lib/go/proxy/golang.org/x/sys/@v/v0.0.0-20220309202614-04245dca01da.mod: no such file or directory
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x7d28ad]

goroutine 1 [running]:
cmd/go/internal/modload.(*loader).checkMultiplePaths(0xc00003a580)
        /usr/lib/go/src/cmd/go/internal/modload/load.go:1747 +0x2d
cmd/go/internal/modload.loadFromRoots({0xa70580, 0xc0000266d0}, {{{0x0, 0x0}, 0xc0001ddce0, 0x1, {0x0, 0x0}, 0x1, 0x1, ...}, ...})
        /usr/lib/go/src/cmd/go/internal/modload/load.go:1122 +0xd78
cmd/go/internal/modload.LoadPackages({0xa70580, 0xc0000266d0}, {{0x0, 0x0}, 0xc0001ddce0, 0x1, {0x0, 0x0}, 0x1, 0x1, ...}, ...)
        /usr/lib/go/src/cmd/go/internal/modload/load.go:329 +0x328
cmd/go/internal/modcmd.runTidy({0xa70580, 0xc0000266d0}, 0xc0000329c0, {0xc0000200b0, 0x4, 0x35})
        /usr/lib/go/src/cmd/go/internal/modcmd/tidy.go:114 +0x1b7
main.invoke(0xd7f5e0, {0xc0000200a0, 0x2, 0x2})
        /usr/lib/go/src/cmd/go/main.go:216 +0x2f6
main.main()
        /usr/lib/go/src/cmd/go/main.go:173 +0x78e

@bcmills bcmills self-assigned this Mar 10, 2022
@bcmills bcmills added modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Mar 10, 2022
@bcmills bcmills added this to the Go1.19 milestone Mar 10, 2022
@bcmills bcmills modified the milestones: Go1.19, Backlog Jun 1, 2022
@bcmills
Copy link
Contributor

bcmills commented Jun 1, 2022

I started looking into this but realized that I don't actually have the steps to reproduce the failure — what module were you in when you observed the segfaults, checked out at what commit, and what go command did you invoke that segfaulted?

@bcmills bcmills added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Jun 1, 2022
@10ne1
Copy link
Author

10ne1 commented Jun 1, 2022

I was running go mod download and go mod tidy configured with a local path-based modules proxy.

The code which reproduces this is rather complex because it integrates Go modules with the Gentoo & ChromiumOS portage build system.

What I think is a very important information is the module versions in the proxy change from the upstream versions because portage can modify / patch the modules it installs into the proxy. The module versions can be non-deterministic because they are generated by the portage build system.

For example:

  1. Module A depends on B which depends on module C. (A -> B -> C). They are all installed in the proxy and the versions are consistent.

  2. Portage rebuilds B and gives it a new version, but does not rebuild A and C. Both A and C depend on the old version which is not in the proxy anymore.

  3. When building another module which depends on A, B or C, the Go modules system will report like in the errors above: reading ... *.mod: no such file or directory then crash.

The "module not found error" is expected. What is not expected is the crash.

The workaround I use for now is to instruct portage to generate deterministic versions for each module installed in the proxy. Not sure if having non-deterministic versions is a good idea, likely not.

@bcmills bcmills removed the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Jun 1, 2022
@bcmills
Copy link
Contributor

bcmills commented Jun 1, 2022

Ah, I think the problem is here:
https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/modload/load.go;l=1176;drc=8a56c7742d96c8ef8e8dcecaf3d1c0e9f022f708

There is a call to ld.errorf, but it is missing a corresponding call to base.ExitIfErrors, and at any rate we shouldn't be assigning ld.requirements = rs at all if rs == nil:
https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/modload/load.go;l=1191;drc=8a56c7742d96c8ef8e8dcecaf3d1c0e9f022f708

@bcmills bcmills added NeedsFix The path to resolution is known, but the work has not been done. help wanted labels Jun 1, 2022
@gopherbot gopherbot removed the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 1, 2022
@bcmills bcmills mentioned this issue Jul 7, 2022
Closed
@gopherbot
Copy link

Change https://go.dev/cl/427054 mentions this issue: cmd/go/internal/modload: return error when tidyRoots fail

@dmitshur dmitshur modified the milestones: Backlog, Go1.20 Oct 8, 2022
romaindoumenc pushed a commit to TroutSoftware/go that referenced this issue Nov 3, 2022
@ianwoolf @romaindoumenc
cmd/go/internal/modload: return error when tidyRoots fail
05e09ca 
Fixes golang#51589

Change-Id: Ie9c56110754f4a435b22e2d7a86ae34b0bd28909
Reviewed-on: https://go-review.googlesource.com/c/go/+/427054
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
@golang golang locked and limited conversation to collaborators Oct 14, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@bcmills bcmills

Labels
FrozenDueToAge modules NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.20
Development

No branches or pull requests
4 participants
@dmitshur @bcmills @gopherbot @10ne1