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

cmd/go: get: panic: internal error: can't find reason for requirement on golang.org/x/sync@... #56494

Closed
icio opened this issue Oct 31, 2022 · 41 comments
Assignees
Labels
GoCommand cmd/go modules NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@icio
Copy link

icio commented Oct 31, 2022

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

$ gotip version
go version devel go1.20-e09bbae Sat Oct 29 04:48:07 2022 +0000 linux/amd64

Same result with 1.18.6, 1.19.

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=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/icio/.cache/go-build"
GOENV="/home/icio/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/icio/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/icio/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/icio/sdk/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/icio/sdk/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="devel go1.20-e09bbae Sat Oct 29 04:48:07 2022 +0000"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/icio/go/src/github.com/icio/go-get-panic/go.mod"
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 -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2460736486=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Run go get -u golang.org/x/tools with go.mod:

module github.com/icio/go-get-panic

go 1.18

require (
	golang.org/x/net v0.1.0
	golang.org/x/sync v0.0.0-20220601150217-0de741cfad7f
	golang.org/x/text v0.4.0
)

What did you expect to see?

go.mod updated with latest golang.org/x/tools version.

What did you see instead?

panic: internal error: can't find reason for requirement on golang.org/x/sync@v0.0.0-20220601150217-0de741cfad7f

goroutine 1 [running]:
cmd/go/internal/modget.(*resolver).updateBuildList.func1({{0xc0000281e0, 0x11}, {0xc000032690, 0x22}})
        /home/icio/sdk/gotip/src/cmd/go/internal/modget/get.go:1760 +0xd4
cmd/go/internal/modget.(*resolver).updateBuildList(0xc00023c000, {0xb2d5d0, 0xc00002c0f8}, {0x0, 0x0, 0x0})
        /home/icio/sdk/gotip/src/cmd/go/internal/modget/get.go:1765 +0x54c
cmd/go/internal/modget.(*resolver).resolveQueries(0xc00023c000, {0xb2d5d0, 0xc00002c0f8}, {0xc000014058, 0x1, 0xc0000a3d78?})
        /home/icio/sdk/gotip/src/cmd/go/internal/modget/get.go:1243 +0x1a5
cmd/go/internal/modget.runGet({0xb2d5d0, 0xc00002c0f8}, 0xc0000285e8?, {0xc0000240f0, 0x1, 0x1})
        /home/icio/sdk/gotip/src/cmd/go/internal/modget/get.go:314 +0x408
main.invoke(0xe371a0, {0xc0000240d0, 0x3, 0x3})
        /home/icio/sdk/gotip/src/cmd/go/main.go:225 +0x3d9
main.main()
        /home/icio/sdk/gotip/src/cmd/go/main.go:179 +0x7ce

To reproduce

$ git clone https://github.com/icio/go-get-panic
Cloning into 'go-get-panic'...
remote: Enumerating objects: 7, done.
remote: Counting objects: 100% (7/7), done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 7 (delta 1), reused 7 (delta 1), pack-reused 0
Receiving objects: 100% (7/7), done.
Resolving deltas: 100% (1/1), done.

$ cd go-get-panic

$ git checkout 2cbc2db2a48105fa2b71ec69d11b6496ba52c263

$ git rev-parse HEAD
2cbc2db2a48105fa2b71ec69d11b6496ba52c263

$ gotip version
go version devel go1.20-e09bbae Sat Oct 29 04:48:07 2022 +0000 linux/amd64

$ gotip get -u golang.org/x/tools
panic: internal error: can't find reason for requirement on golang.org/x/sync@v0.0.0-20220601150217-0de741cfad7f

goroutine 1 [running]:
cmd/go/internal/modget.(*resolver).updateBuildList.func1({{0xc0000281e0, 0x11}, {0xc000032690, 0x22}})
        /home/icio/sdk/gotip/src/cmd/go/internal/modget/get.go:1760 +0xd4
cmd/go/internal/modget.(*resolver).updateBuildList(0xc00023c000, {0xb2d5d0, 0xc00002c0f8}, {0x0, 0x0, 0x0})
        /home/icio/sdk/gotip/src/cmd/go/internal/modget/get.go:1765 +0x54c
cmd/go/internal/modget.(*resolver).resolveQueries(0xc00023c000, {0xb2d5d0, 0xc00002c0f8}, {0xc000014058, 0x1, 0xc0000a3d78?})
        /home/icio/sdk/gotip/src/cmd/go/internal/modget/get.go:1243 +0x1a5
cmd/go/internal/modget.runGet({0xb2d5d0, 0xc00002c0f8}, 0xc0000285e8?, {0xc0000240f0, 0x1, 0x1})
        /home/icio/sdk/gotip/src/cmd/go/internal/modget/get.go:314 +0x408
main.invoke(0xe371a0, {0xc0000240d0, 0x3, 0x3})
        /home/icio/sdk/gotip/src/cmd/go/main.go:225 +0x3d9
main.main()
        /home/icio/sdk/gotip/src/cmd/go/main.go:179 +0x7ce

This reproduces even if you remove the go.sum:

$ rm go.sum && gotip get -u golang.org/x/tools 2>&1 | head -1
panic: internal error: can't find reason for requirement on golang.org/x/sync@v0.0.0-20220601150217-0de741cfad7f

Uncommenting any of the requirements in go.mod and re-running go get -u golang.org/x/tools will allow go get to succeed. E.g.:

$ sed -i '/x\/net/d' go.mod  

$ git diff
diff --git a/go.mod b/go.mod
index cc0392c..05b38b1 100644
--- a/go.mod
+++ b/go.mod
@@ -3,7 +3,6 @@ module github.com/icio/go-get-panic
 go 1.18
 
 require (
-       golang.org/x/net v0.1.0
        golang.org/x/sync v0.0.0-20220601150217-0de741cfad7f
        golang.org/x/text v0.4.0
 )

$ go get -u golang.org/x/tools
go: downgraded golang.org/x/text v0.4.0 => v0.3.7
go: upgraded golang.org/x/tools v0.1.12 => v0.2.0

In the repository where I first encountered, this I was able to fix go get -u golang.org/x/tools by removing the golang.org/x/sync v0.0.0-20220601150217-0de741cfad7f line. Next, re-running go mod tidy reintroduces golang.org/x/sync v0.0.0-20220601150217-0de741cfad7f to go.mod. I'm not sure if this is related, but despite having a ./go.mod at the root of the project, we also have a ./cmd/ci-test-utility/go.mod which contains golang.org/x/sync v0.0.0-20220601150217-0de741cfad7f.

@icio icio changed the title affected/package: go get: panic: internal error: can't find reason for requirement on golang.org/x/sync@... Oct 31, 2022
@icio
Copy link
Author

icio commented Oct 31, 2022

There's a few other people tripping over this in #47979

@icio icio changed the title go get: panic: internal error: can't find reason for requirement on golang.org/x/sync@... cmd/go: get: panic: internal error: can't find reason for requirement on golang.org/x/sync@... Oct 31, 2022
@seankhliao seankhliao added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. GoCommand cmd/go labels Nov 1, 2022
@bcmills bcmills self-assigned this Nov 1, 2022
@bcmills bcmills added the modules label Nov 1, 2022
@bcmills bcmills added this to the Backlog milestone Nov 1, 2022
@bcmills
Copy link
Contributor

bcmills commented Nov 2, 2022

I see exactly the behavior that you describe. Thank you for distilling it down to a simple reproducer!

@bcmills
Copy link
Contributor

bcmills commented Nov 2, 2022

The conflict in this example is:

go: golang.org/x/tools@upgrade (v0.2.0) requires golang.org/x/sync@v0.0.0-20220722155255-886fb9371eb4, not (INTERNAL ERROR: no reason found for golang.org/x/sync@v0.0.0-20220601150217-0de741cfad7f)

For some reason modload.editRequirements things that golang.org/x/tools@v0.2.0 requires golang.org/x/sync@v0.0.0-20220722155255-886fb9371eb4, but the limits haven't been updated to allow that version, and with good reason: with graph pruning in effect, golang.org/x/tools@v0.2.0 doesn't depend on golang.org/x/sync at all:

~/x/tools$ git checkout v0.2.0
HEAD is now at f112c4332 go.mod: update golang.org/x dependencies

~/x/tools$ go list -m golang.org/x/sync
go: module golang.org/x/sync: not a known dependency

So I think this is another symptom of #55955.

@bcmills
Copy link
Contributor

bcmills commented Nov 2, 2022

This arises from a dependency cycle that should be pruned out but isn't:

golang.org/x/tools@v0.2.0 golang.org/x/net@v0.1.0
golang.org/x/net@v0.1.0 golang.org/x/text@v0.4.0
golang.org/x/text@v0.4.0 golang.org/x/tools@v0.1.12
golang.org/x/tools@v0.1.12 golang.org/x/sync@v0.0.0-20220722155255-886fb9371eb4

The cycle isn't pruned because each of the module paths involved in the cycle appears explicitly in the reproducer's go.mod file, which causes those dependencies to be followed (because as far as the versionLimiter knows at that point they could become selected):
https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/modload/edit.go;l=598-603;drc=5f305ae8e5796ea3821088863a6842117c58da72

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/447797 mentions this issue: cmd/go: add a test that reproduces the root cause of issue #56494

jimmykarily pushed a commit to kairos-io/provider-kairos that referenced this issue Nov 4, 2022
It makes the tests fail, possible because of this:

golang/go#47979
golang/go#56494
jimmykarily pushed a commit to kairos-io/provider-kairos that referenced this issue Nov 4, 2022
It makes the tests fail, possible because of this:

golang/go#47979
golang/go#56494
Signed-off-by: Dimitris Karakasilis <dimitris@karakasilis.me>
@godcong
Copy link

godcong commented Nov 17, 2022

I tried the temporary solution to force the version number of sync to solve the problem.

replace golang.org/x/sync v0.0.0-20210220032951-036812b2e83c => golang.org/x/sync v0.1.0

@bcmills
Copy link
Contributor

bcmills commented Nov 18, 2022

@godcong, the best temporary workaround is probably to just manually update the require line for golang.org/x/sync to the version you want and then run go mod tidy to clean it up.

(This bug does not affect go mod tidy, only go get.)

@godcong
Copy link

godcong commented Nov 21, 2022

@godcong, the best temporary workaround is probably to just manually update the line for to the version you want and then run to clean it up.require``golang.org/x/sync``go mod tidy

(This bug does not affect , only .)go mod tidy``go get

I have tried this program
I used go get sync@v0.1.0 to update sync to v0.1.0
but it still gives me an error when implementing go mod tidy.
Maybe it is because my main project does not use sync.

@icio
Copy link
Author

icio commented Nov 21, 2022

@godcong Removing all mention of golang.org/x/sync from go.mod then running my original go get command fixed it all for me.

@godcong
Copy link

godcong commented Nov 21, 2022

@godcong Removing all mention of golang.org/x/sync from go.mod then running my original command fixed it all for me.go get

I can't delete it, because it's an open source project on github.
I just imported to this project...
I'll just have to wait for the owner of this project to fix it... :(

@KinaneD
Copy link

KinaneD commented Nov 28, 2022

Same here.
Version:

go version
go version go1.18.8 linux/arm64

Installing Cloud Storage:

go get cloud.google.com/go/storage
panic: internal error: can't find reason for requirement on github.com/jstemmer/go-junit-report@v0.0.0-20190106144839-af01ea7f8024

goroutine 1 [running]:
cmd/go/internal/modget.(*resolver).updateBuildList.func1({{0x4000228450?, 0x40000b1560?}, {0x40001005a0?, 0x4000300950?}})
	/usr/local/go/src/cmd/go/internal/modget/get.go:1760 +0xf8
cmd/go/internal/modget.(*resolver).updateBuildList(0x40001c6000, {0x679140, 0x4000026060}, {0x0, 0x0, 0x0})
	/usr/local/go/src/cmd/go/internal/modget/get.go:1765 +0x454
cmd/go/internal/modget.(*resolver).resolveQueries(0x40001c6000, {0x679140, 0x4000026060}, {0x4000010058, 0x1, 0x563e40?})
	/usr/local/go/src/cmd/go/internal/modget/get.go:1243 +0x17c
cmd/go/internal/modget.runGet({0x679140, 0x4000026060}, 0x4000024480?, {0x40000201d0, 0x1, 0x1})
	/usr/local/go/src/cmd/go/internal/modget/get.go:314 +0x394
main.invoke(0x951a00, {0x40000201c0, 0x2, 0x2})
	/usr/local/go/src/cmd/go/main.go:218 +0x2b0
main.main()
	/usr/local/go/src/cmd/go/main.go:175 +0x788

Upgrading go-junit-report did not resolve:

go install github.com/jstemmer/go-junit-report/v2@latest
go: downloading github.com/jstemmer/go-junit-report v1.0.0
go: downloading github.com/jstemmer/go-junit-report/v2 v2.0.0

@clarkmcc
Copy link

clarkmcc commented Dec 1, 2022

Same as @KinaneD

When running

go get cloud.google.com/go/storage

On

$ go version
go version go1.19.3 darwin/arm64

I get the following stack trace

$ go get cloud.google.com/go/storage
go: downloading cloud.google.com/go/storage v1.28.0
go: downloading cloud.google.com/go v0.107.0
go: downloading cloud.google.com/go/iam v0.5.0
go: downloading cloud.google.com/go/compute/metadata v0.2.1
go: downloading github.com/googleapis/gax-go/v2 v2.6.0
go: downloading golang.org/x/oauth2 v0.0.0-20221014153046-6fdb5e3db783
go: downloading google.golang.org/api v0.102.0
go: downloading google.golang.org/genproto v0.0.0-20221024183307-1bc688fe9f3e
go: downloading cloud.google.com/go/compute v1.12.1
go: downloading google.golang.org/grpc v1.50.1
go: downloading golang.org/x/net v0.0.0-20221014081412-f15817d10f9b
go: downloading github.com/googleapis/enterprise-certificate-proxy v0.2.0
panic: internal error: can't find reason for requirement on github.com/stretchr/testify@v1.6.1

goroutine 1 [running]:
cmd/go/internal/modget.(*resolver).updateBuildList.func1({{0x140005ab580?, 0x140003cce10?}, {0x140001a29a0?, 0x1400029c6e0?}})
        /opt/homebrew/Cellar/go/1.19.3/libexec/src/cmd/go/internal/modget/get.go:1760 +0xf8
cmd/go/internal/modget.(*resolver).updateBuildList(0x14000438200, {0x104b0a510, 0x140001a2000}, {0x0, 0x0, 0x0})
        /opt/homebrew/Cellar/go/1.19.3/libexec/src/cmd/go/internal/modget/get.go:1765 +0x450
cmd/go/internal/modget.(*resolver).applyUpgrades(0x14000438200, {0x104b0a510, 0x140001a2000}, {0x0?, 0x1?, 0x104aef8a0?})
        /opt/homebrew/Cellar/go/1.19.3/libexec/src/cmd/go/internal/modget/get.go:1312 +0xc0
cmd/go/internal/modget.runGet({0x104b0a510, 0x140001a2000}, 0x140001bc348?, {0x1400019e1a0, 0x1, 0x1})
        /opt/homebrew/Cellar/go/1.19.3/libexec/src/cmd/go/internal/modget/get.go:351 +0x3c8
main.invoke(0x104dfe280, {0x1400019e190, 0x2, 0x2})
        /opt/homebrew/Cellar/go/1.19.3/libexec/src/cmd/go/main.go:225 +0x2f8
main.main()
        /opt/homebrew/Cellar/go/1.19.3/libexec/src/cmd/go/main.go:179 +0x7ac

@godcong
Copy link

godcong commented Dec 9, 2022

go 1.19.4 released, has anyone tried it?
Does this problem still exist?

@Jorropo
Copy link
Member

Jorropo commented Dec 9, 2022

@godcong yes ipfs/kubo#9423 (comment) (I tried with go1.19.4 and e76c87b)

@KinaneD
Copy link

KinaneD commented Dec 9, 2022

Hi @clarkmcc I ended up upgrading the dependency that required the conflicting package.
I recommend you start from there.
Good luck.

@Jorropo
Copy link
Member

Jorropo commented Dec 9, 2022

I have bisected the issue to 9a81702 (first bad commit).

I have multiple failing packages which are deeply connected in my dependency graph making the workaround of upgrading everything / removing them very unpractical.

bflad added a commit to bflad/tfproviderlint that referenced this issue Apr 13, 2023
Reference: #255
Reference: golang/go#56494

Manual upgrade due to prior Go panic:

```console
$ go get golang.org/x/tools@v0.8.0
panic: internal error: can't find reason for requirement on golang.org/x/crypto@v0.0.0-20200622213623-75b288015ac9

goroutine 1 [running]:
cmd/go/internal/modget.(*resolver).updateBuildList.func1({{0x1400043ed80, 0x13}, {0x140000c2e70, 0x22}})
        /opt/homebrew/Cellar/go/1.20.3/libexec/src/cmd/go/internal/modget/get.go:1760 +0xc4
cmd/go/internal/modget.(*resolver).updateBuildList(0x1400007e000, {0x100f55398, 0x1400009e000}, {0x0, 0x0, 0x0})
        /opt/homebrew/Cellar/go/1.20.3/libexec/src/cmd/go/internal/modget/get.go:1765 +0x41c
cmd/go/internal/modget.(*resolver).resolveQueries(0x1400007e000, {0x100f55398, 0x1400009e000}, {0x140000b0090, 0x1, 0x10126bde0?})
        /opt/homebrew/Cellar/go/1.20.3/libexec/src/cmd/go/internal/modget/get.go:1243 +0x148
cmd/go/internal/modget.runGet({0x100f55398, 0x1400009e000}, 0x140000b8600?, {0x1400009a1a0, 0x1, 0x1})
        /opt/homebrew/Cellar/go/1.20.3/libexec/src/cmd/go/internal/modget/get.go:314 +0x38c
main.invoke(0x10125e3c0, {0x1400009a190, 0x2, 0x2})
        /opt/homebrew/Cellar/go/1.20.3/libexec/src/cmd/go/main.go:225 +0x37c
main.main()
        /opt/homebrew/Cellar/go/1.20.3/libexec/src/cmd/go/main.go:179 +0x7cc
```

Updated via:

```shell
go get golang.org/x/crypto@latest # panic workaround
go get golang.org/x/tools@v0.8.0
go mod tidy
go mod vendor
```

Introduces `xpasses/XR007` and `xpasses/XR008` test skips due to `golang.org/x/tools` now properly returning an error with invalid source files. This is expected with the suggested fixes implementation since those will intentionally remove source code, leaving the source code in an unbuildable state to encourage the developer to figure out the rest of the necessary solution.
dimakow added a commit to dimakow/netcup that referenced this issue Apr 18, 2023
@bcmills
Copy link
Contributor

bcmills commented Apr 24, 2023

I've mailed CL 471595 with a proposed fix. Folks who are affected by this bug: please try out a build with that change (either now or after it is merged) and let me know if any problems remain.

That change may also fix some of the “infinite hang” problems, since it fixes a source of errors in the build list. (go get iterates until the build list stabilizes, and I observed some infinite loops in testing caused by pruned dependencies being reintroduced or repeatedly re-eliminated.)

@francislavoie
Copy link

I don't have any experience with gerrit. Are there instructions somewhere I could follow? Or is there a branch on GitHub I can pull from?

One key point for Caddy in particular is that we can't build from a Go version which reports 1.21 because quic-go has custom crypto/tls code and only has implementations ready for stable releases. Is there a simple way of making Go report 1.20 for purposes of testing with these changes?

@bcmills
Copy link
Contributor

bcmills commented Apr 24, 2023

I don't have any experience with gerrit. Are there instructions somewhere I could follow? Or is there a branch on GitHub I can pull from?

There is a Download patch button at the top of the diffs:
image

Is there a simple way of making Go report 1.20 for purposes of testing with these changes?

Unfortunately no. You could perhaps patch go-quic to force it to try building (or add a tag that you could set to force it to try building)?

You could also run go get using a go built from head, but then do the actual go build or go install with an older release. (The go.mod file produced by the updated go get should still be interpreted correctly by previous releases.)

@francislavoie
Copy link

Unfortunately no. You could perhaps patch go-quic to force it to try building (or add a tag that you could set to force it to try building)?

That's not an option, because quic-go upgrading ginkgo was the cause of our problems. If we removed it, then it would certainly work. Our repoducer is specifically with a newer Caddy version as the base, with a Caddy plugin that depends on an older version of Caddy, where the newer base had upgraded quic-go.

@mholt
Copy link

mholt commented Apr 24, 2023

Thank you for implementing a hopeful patch/fix! 🎉 💙 We are very grateful for this progress.

Unfortunately no.

As in, impossible? We're not sure how to test this any other way, since if we mess with the dependency that caused the bug in the first place we can't be sure it's a good test of the patch.

@bcmills
Copy link
Contributor

bcmills commented Apr 24, 2023

@mholt, you could patch the Go toolchain to pretend that it's 1.20, but in this sort of case — especially since quic-go/quic-go#2727 was filed back in 2020 — it's kind of “you break it, you get to keep all the pieces”. Reaching into release-specific internals of the standard library is definitely not something the Go project supports. 🤷‍♂️

@mholt
Copy link

mholt commented Apr 24, 2023

Totally understand 💯 That's probably acceptable since it's just a local change in a disposable environment for testing a PR. We'll see if we get a chance here soon to try it.

@anacrolix
Copy link
Contributor

@bcmills The CL fixes this issue for me too. Specifically in anacrolix/torrent#421 (comment) I saw

~/src/rms-torrent [2]% go1.19 get github.com/anacrolix/torrent@latest
panic: internal error: can't find reason for requirement on github.com/mattn/go-sqlite3@v1.14.16

goroutine 1 [running]:
cmd/go/internal/modget.(*resolver).updateBuildList.func1({{0x14000029640?, 0x140001b37a0?}, {0x140001a2fa8?, 0x14000112b20?}})
	/Users/anacrolix/src/go1.19/src/cmd/go/internal/modget/get.go:1760 +0xf8
cmd/go/internal/modget.(*resolver).updateBuildList(0x14000412000, {0x102b7ae90, 0x140001a2000}, {0x0, 0x0, 0x0})
	/Users/anacrolix/src/go1.19/src/cmd/go/internal/modget/get.go:1765 +0x450
cmd/go/internal/modget.(*resolver).resolveQueries(0x14000412000, {0x102b7ae90, 0x140001a2000}, {0x140001b4048, 0x1, 0x102b601e0?})
	/Users/anacrolix/src/go1.19/src/cmd/go/internal/modget/get.go:1243 +0x180
cmd/go/internal/modget.runGet({0x102b7ae90, 0x140001a2000}, 0x140001be420?, {0x1400019e1a0, 0x1, 0x1})
	/Users/anacrolix/src/go1.19/src/cmd/go/internal/modget/get.go:314 +0x38c
main.invoke(0x102e6e2c0, {0x1400019e190, 0x2, 0x2})
	/Users/anacrolix/src/go1.19/src/cmd/go/main.go:225 +0x2f8
main.main()
	/Users/anacrolix/src/go1.19/src/cmd/go/main.go:179 +0x7ac

And now I get

~/src/rms-torrent [2]% go get github.com/anacrolix/torrent@latest
go: upgraded github.com/anacrolix/torrent v1.49.0 => v1.49.1

@anacrolix
Copy link
Contributor

I think I still get the infinite hang I mentioned at #56494 (comment).

@bcmills
Copy link
Contributor

bcmills commented Apr 26, 2023

@anacrolix, if you're getting an infinite hang try running go get with -v and/or sending SIGQUIT, and please do file a separate issue.

@bcmills
Copy link
Contributor

bcmills commented May 12, 2023

The original steps to reproduce this issue no longer do, but I'm quite confident that it is a symptom of #55955 and will be fixed by https://go.dev/cl/471595.

@bcmills
Copy link
Contributor

bcmills commented May 12, 2023

Duplicate of #55955

@bcmills bcmills marked this as a duplicate of #55955 May 12, 2023
@bcmills bcmills closed this as not planned Won't fix, can't repro, duplicate, stale May 12, 2023
@icio
Copy link
Author

icio commented May 12, 2023

Thank you for all your great work, @bcmills :)

gopherbot pushed a commit that referenced this issue May 17, 2023
For #56494.

Change-Id: I9bbded6d014ac73d81b973f2d7b4783e64380031
Reviewed-on: https://go-review.googlesource.com/c/go/+/447797
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
gopherbot pushed a commit that referenced this issue May 17, 2023
Prior to this change, 'go get' pulled in every version of each module
whose path is explicitly listed in the go.mod file. When graph pruning
is enabled (that is, when the main module is at 'go 1.17' or higher),
that pulled in transitive dependencies of older-than-selected versions
of dependencies, which are normally pruned out by other 'go' commands
(including 'go mod tidy' and 'go mod graph').

To make matters worse, different parts of `go get` were making
different assumptions about which kinds of conflicts would be
reported: the modget package assumed that any conflict is necessarily
due to some explicit constraint, but 'go get' was imposing an
additional constraint that modules could not be incidentally upgraded
in the course of a downgrade. When that additional constraint failed,
the modload package reported the failure as though it were a real
(caller-supplied) constraint, confusing the caller (which couldn't
identify any specific package or argument that caused the failure).

This change fixes both of those problems by replacing the
modload.EditRequirements algorithm with a different one.

The new algorithm is, roughly, as follows.

1. Propose a list of “root requirements” to be written to the updated
   go.mod file.

2. Load the module graph from those requirements mostly as usual, but
   if any root is upgraded due to transitive dependencies, retain the
   original roots and the paths leading from those roots to the
   upgrades. (This forms an “extended graph”, in which we can trace a
   path from to each version that appears in the graph starting at one
   or more of the original roots.)

3. Identify which roots caused any module path to be upgraded above
   its passed-in version constraint. For each such root, either report
   an unresolvable conflict (if the root itself is constrained to a
   specific version) or identify an updated version to propose: either
   a downgrade to the next-highest version, or an upgrade to the
   actually-selected version of the root (if that version is allowed).
   To avoid looping forever or devolving into an NP-complete search,
   we never propose a version that was already rejected previously,
   regardless of what other roots were present alongside it at the
   time.

4. If the version of any root was changed, repeat from (1).

This algorithm is guaranteed to terminate, because there are finitely
many root versions and we permanently reject at least one each time we
downgrade its path to a lower version.

In addition, this change implements support for the '-v' flag to log
more information about version changes at each iteration.

Fixes #56494.
Fixes #55955.

Change-Id: Iebc17dd7586594d5732e228043c3c4c6da230f44
Reviewed-on: https://go-review.googlesource.com/c/go/+/471595
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
@bcmills bcmills modified the milestones: Backlog, Go1.21 Aug 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
GoCommand cmd/go modules NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests