cmd/go: get: panic: internal error: can't find reason for requirement on golang.org/x/sync@... #56494
Comments
icio
changed the title
|
There's a few other people tripping over this in #47979 |
icio
changed the title
seankhliao
added
NeedsInvestigation
|
I see exactly the behavior that you describe. Thank you for distilling it down to a simple reproducer! |
|
The conflict in this example is: For some reason So I think this is another symptom of #55955. |
|
This arises from a dependency cycle that should be pruned out but isn't: The cycle isn't pruned because each of the module paths involved in the cycle appears explicitly in the reproducer's |
|
Change https://go.dev/cl/447797 mentions this issue: |
It makes the tests fail, possible because of this: golang/go#47979 golang/go#56494
It makes the tests fail, possible because of this: golang/go#47979 golang/go#56494 Signed-off-by: Dimitris Karakasilis <dimitris@karakasilis.me>
|
I tried the temporary solution to force the version number of sync to solve the problem. |
|
@godcong, the best temporary workaround is probably to just manually update the (This bug does not affect |
I have tried this program |
|
@godcong Removing all mention of golang.org/x/sync from go.mod then running my original |
I can't delete it, because it's an open source project on github. |
|
Same here. Installing Cloud Storage: Upgrading go-junit-report did not resolve: |
|
Same as @KinaneD When running On I get the following stack trace |
|
|
|
@godcong yes ipfs/kubo#9423 (comment) (I tried with go1.19.4 and e76c87b) |
|
Hi @clarkmcc I ended up upgrading the dependency that required the conflicting package. |
|
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. |
|
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. ( |
|
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 |
There is a
Unfortunately no. You could perhaps patch You could also run |
That's not an option, because |
|
Thank you for implementing a hopeful patch/fix! 🎉 💙 We are very grateful for this progress.
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. |
|
@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. 🤷♂️ |
|
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. |
|
@bcmills The CL fixes this issue for me too. Specifically in anacrolix/torrent#421 (comment) I saw And now I get |
|
I think I still get the infinite hang I mentioned at #56494 (comment). |
|
@anacrolix, if you're getting an infinite hang try running |
|
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. |
|
Duplicate of #55955 |
|
Thank you for all your great work, @bcmills :) |
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>
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>
What version of Go are you using (
go version)?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 envOutputWhat did you do?
Run
go get -u golang.org/x/toolswith go.mod:What did you expect to see?
go.mod updated with latest golang.org/x/tools version.
What did you see instead?
To reproduce
This reproduces even if you remove the go.sum:
Uncommenting any of the requirements in go.mod and re-running
go get -u golang.org/x/toolswill allowgo getto succeed. E.g.:In the repository where I first encountered, this I was able to fix
go get -u golang.org/x/toolsby removing thegolang.org/x/sync v0.0.0-20220601150217-0de741cfad7fline. Next, re-runninggo mod tidyreintroducesgolang.org/x/sync v0.0.0-20220601150217-0de741cfad7fto 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 containsgolang.org/x/sync v0.0.0-20220601150217-0de741cfad7f.The text was updated successfully, but these errors were encountered: