cmd/go: get hangs without error output from unknown revisions #53905
Labels
GoCommand
cmd/go
modules
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
WaitingForInfo
Issue is not actionable because of missing required information, which needs to be provided.
Milestone
Comments
|
FYI: Step 3 of the steps to reproduce produced no output related to the hanging behavior or to the underlying invalid versions being referenced, even with the |
mknyszek
added
NeedsInvestigation
bcmills
added
the
WaitingForInfo
bcmills
removed
the
WaitingForInfo
|
@Justin-W, what happens if you send |
bcmills
added
the
WaitingForInfo
@bcmills This is the SIGQUIT dump when the process for |
bcmills
removed
the
WaitingForInfo
|
I am having the same issue on a M1 Mac unfortunately. |
|
I have another reproducible case when building Caddy with our build tool In this situation, we're building a newer version of Caddy and trying to plugin another package which depends on an older version of Caddy. Admittedly this might be a bit noisy because both Details |
|
The |
This was referenced Mar 8, 2023
|
I am experiencing the same issue trying to build dolthub/dolt on Linux/ARM64 (Lenovo Chromebook, Crostini, Debian Sid). Building with GOARCH=arm64 on my Linux/AMD64 VPS and then copying to the system circumvents the issue. Can this be an issue with how the Go tool is compiled with ARM64 specific elements? |
25 tasks
|
i have same problem, m1 pro |
|
Hi, looking at this issue, I don't see concrete reproduction steps that can run using only the go tools and already existing repos. I'd like to see if there's a simple reproduction that consistently fails (or often fails in n runs) that we could start with. |
seankhliao
added
the
WaitingForInfo
|
Timed out in state WaitingForInfo. Closing. (I am just a bot, though. Please speak up if this is a mistake or you have the requested information.) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What version of Go are you using (
go version)?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?
Adepended on byBdepended on byC(so C indirectly depends on A)go.modreference to A invalid(for us, A's git history was rewritten; but you could probably manually edit B's go.mod with a invalid pseudo-version to get the same effect)
go get -u ./...in either B or C (or any module that depends on either of them)goprocess to hang with high CPU, then terminate itgo list -m -u -json all | jq --raw-output 'select((.Indirect or .Main)|not) | .Path' | xargs -t -I % go get -u -t %@latest, to find any "error:" or "panic:" outputgo.*files resulting from step 5.What did you expect to see?
Either some output indicating the dependency reference problem(s), or else normal operation of the
go get ...command in step 3.What did you see instead?
Step 3 starts running normally (there may or may not be some output, downloads, etc., with typical levels of CPU by the process), but at some point all output ceases and CPU spikes to 350%-450% and stays basically flat at that level until the
goprocess is terminated.Step 5 did not hang, and output contained several sections with errors like these:
Workaround
replacedirective for each of the "invalid version"s identified in step 5 to thego.modfiles of each dependent repo (including indirectly-dependent ones).Notes:
go getbehavior ceased.go.modreference to 1 of the 4 "missing revision"s which were in the error output. The other 3 seemed to be referenced exclusively from historical versions ofgo.modandgo.sumfiles (e.g. the git history of no-longer-referenced versions of certain modules), but not by any versions which were still directly referenced. IDK how un-referenced versions'go.*contents could still be affectinggo getbehavior, but it seemed to be the case. Very weird. If true, more details would be appreciated, since that might indicate that thereplacedirectives need to remain in place forever (which would be unfortunate).go.*files even on affected envs.)go 1.17orgo 1.18directives in theirgo.modfiles. We weren't attempting to preserve pre-v1.17 compatibility.v0.0.0-20220203083605-df6cd891c11a) did not work as a workaround.go.modrefs which get broken as a result of commits which get irrevocably deleted. That would be much preferred vs thereplacedirectives workaround.retractdirectives to the repos which were the source of the "missing" versions did not resolve the problem. (Would've been much nicer if it had, so that the samereplacedirectives didn't need to be replicated in dozens of dependent repos.)retractisn't intended to prevent a dependent repo from referencing a retracted version once it already is, but since I was actually trying to upgrade all the deps, it would've been nice if thego get -u ./...command simply updated the "bad" refs with good ones (and didn't hang), which would have allowed me to iteratively upgrade all dependencies to stop using the bad revisions (without the need to manually identify andreplacethe "missing" revisions).The text was updated successfully, but these errors were encountered: