x/tools/gopls: Session.SnapshotOf gets stuck #67289
Assignees
Labels
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Comments
|
Can you try installing [email protected] to see if it fixes your problem? That will help us narrow down the regression. |
|
@findleyr It seems the problem has been fixed. thanks
|
|
I am experiencing the same issue, including after downgrading to [email protected]: Run Run Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders. |
|
@williambao could you use [email protected] with the following settings, and report whether you still have the reported problem saving files? That would help us narrow down the problem. settings.json For both @williambao and @akgerber: does |
|
|
|
@akgerber would you be able to capture RPC logs from a brief VS Code session that reproduces the problem? |
findleyr
added
the
WaitingForInfo
I am suspicious that this message I have been seeing in VSCode may be related.
|
|
I will attempt to capture RPC logs in a test repo. |
|
@akgerber can you try recompiling gopls with go 1.22.2? |
I'll give that a shot, thanks! |
|
Hmm, the issue seems to persist after recompiling |
|
@akgerber hmm, that's interesting. If you can capture RPC logs, it would be very helpful. |
|
Spun up a test repo. Here's a full 
|
|
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.) |
|
Sorry, this is definitely not waiting for info. Apologies that this languished for so long: the team has been very busy with the freeze, and apparently this has tab has been open in my browser for time WaitingForInfo timeout period.... |
findleyr
removed
the
WaitingForInfo
|
Looks like the server was fine until around request 92 and then got stuck: Between 91 and 92 we see these events, indicating that gopls scanned go/pkg/mod, apparently successfully: But after this point, not only codeAction requests, but all requests including semanticTokens (e.g. 95), foldingRange (97), documentSymbol (98), and codeLens (99), all start hanging; no further responses are observed. My guess is Session.SnapshotOf is stuck, but how I do not know. |
adonovan
changed the title
adonovan
added
the
NeedsInvestigation
|
Thanks @adonovan for investigating. |
|
Sorry this took so long to get to, @akgerber and @williambao.
That's actually the background module cache refresh completing. This refresh only populates directories; it does not load exports. The timing is suspicious. Perhaps the the problem may be that the newly scanned module cache simply takes a while to process. Possibly related: I see that imports fixing is not cancellable, which is wrong. I'll fix that. A knock against this theory is that it looks like the unresolved imports are 'os', 'tls', and 'flag', all of which should be satisfied by standard library packages... so in that case you shouldn't even get to the module cache, and even if you did, gopls should only be considering packages with those package names, of which there should be few. Of course, it could be a deadlock, but I've hunted for deadlocks for around an hour and not found any obvious candidates. @akgerber @williambao I wonder if gopls ever gets 'unstuck' when it gets into this phase, for example after a minute or two. If this is reliably reproducible, I can create a patched version of gopls that helps us debug. |
|
Change https://go.dev/cl/589975 mentions this issue: |
gopherbot
pushed a commit
to golang/tools
that referenced
this issue
Jun 3, 2024
Historically, FixImports did not have access to a context, and performed its imports scan with context.Background. Since then, FixImports is called by gopls with the CodeAction Context, yet cancelling this context does not abort the scan. Fix this by using the correct context, and checking context cancellation before parsing. It's a little hard to see that context cancellation doesn't leave the process environent in a broken state, but we can infer that this is OK because other scans (such as that used by unimported completion) do cancel their context. Additionally, remove a 'fixImportsDefault' extensibility seam that is apparently unused after six years. For golang/go#67289 Change-Id: I32261b1bfb38af32880e981cd2423414069b32a3 Reviewed-on: https://go-review.googlesource.com/c/tools/+/589975 LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Robert Findley <[email protected]> Reviewed-by: Alan Donovan <[email protected]>
|
Another thing to try is |
|
Change https://go.dev/cl/590377 mentions this issue: |
gopherbot
pushed a commit
to golang/tools
that referenced
this issue
Jun 5, 2024
An apparent bad merge in CL 561235 caused the critical component-- clearing the resolver for a new scan--to be dropped. Fix this, so that the imports state is actually refreshed asynchronously. It is surprising that this was not reported, though I see perhaps two related comments in survey results. Most likely adding a new import is infrequent enough that users were simply confused, or learned to restart gopls (alas). Also, add more instrumentation that would help debug golang/go#67289. For golang/go#67289 Change-Id: I50d70a470eb393caf9e0b41856997942372b216f Reviewed-on: https://go-review.googlesource.com/c/tools/+/590377 Auto-Submit: Robert Findley <[email protected]> Reviewed-by: Alan Donovan <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
|
I dug into this quite a bit yesterday, and while I don't fully understand what's going on, I have some theories. The logs show the module cache being refreshed here: https://cs.opensource.google/go/x/tools/+/refs/tags/gopls/v0.15.3:gopls/internal/cache/imports.go;l=198;drc=6d4ccf2ad683b5263e582762e1c41de6d0572e4f Furthermore, they show Which suggests that gopls is running GetResolver here: Yet we never see the log message here: Therefore, gopls is hanging in GetResolver. This may be due to the call to I've added additional logging to get more information. If folks experiencing this problem could try again, I'd appreciate it. Additionally, I've made the following mitigations:
I need more information to diagnose at this point, so moving to the v0.17.0 milestone. I think, longer term, we should just rewrite this aspect of goimports entirely, so that the import logic can use gopls' own view of the module and its dependencies. That is probably a better fix than tracking down this bug in the very complicated goimports codebase. |
This was referenced Jun 5, 2024
|
@pjweinb is in the process of rewriting our goimports integration. I think we can wait for that to address this class of issue. Bumping to v0.18.0. |
apstndb
pushed a commit
to apstndb/gotoolsdiff
that referenced
this issue
Jan 11, 2025
An apparent bad merge in CL 561235 caused the critical component-- clearing the resolver for a new scan--to be dropped. Fix this, so that the imports state is actually refreshed asynchronously. It is surprising that this was not reported, though I see perhaps two related comments in survey results. Most likely adding a new import is infrequent enough that users were simply confused, or learned to restart gopls (alas). Also, add more instrumentation that would help debug golang/go#67289. For golang/go#67289 Change-Id: I50d70a470eb393caf9e0b41856997942372b216f Reviewed-on: https://go-review.googlesource.com/c/tools/+/590377 Auto-Submit: Robert Findley <[email protected]> Reviewed-by: Alan Donovan <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
|
The goimports rewrite will be in v0.18.0, though off by default. Moving this to v0.19.0 to confirm that it is fixed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Recently, vscode has become unable to save files normally. Every time I try to save the file, there are will popup a dialog shown in the video below , and will not disappeared.
Saving 'xxx.go': Getting code actions from "Go"CleanShot.2024-04-02.at.12.30.41.mp4
I have tried restarting and reinstalling vscode. but failed to fix the problem.
What version of Go, VS Code & VS Code Go extension are you using?
Version Information
go versionto get version of Go from the VS Code integrated terminal.gopls -v versionto get version of Gopls from the VS Code integrated terminal.code -vorcode-insiders -vto get version of VS Code or VS Code Insiders.Go: Locate Configured Go Toolscommand.Tools Configuration
Environment
GOBIN: undefined
toolsGopath:
gopath: /Users/william/go
GOROOT: /usr/local/go
PATH: /Users/william/miniconda3/bin:/Users/william/miniconda3/condabin:/Users/william/.nvm/versions/node/v21.5.0/bin:/Library/Frameworks/Python.framework/Versions/3.11/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Library/Apple/usr/bin:/usr/local/share/dotnet:~/.dotnet/tools:/usr/local/go/bin:/Users/william/.cargo/bin:/Users/william/.orbstack/bin:/Users/william/go/bin:/bin:/Users/william/Library/Android/sdk/platform-tools:/Users/william/.dotnet/tools
Tools
Go env
Workspace Folder (canzhi-im): /Users/william/dev/github/williambao/canzhi-im
The text was updated successfully, but these errors were encountered: