x/tools/gopls: panic in analysis

[KaurkerDevourer]

gopls version

Build info

golang.org/x/tools/gopls v0.12.0 golang.org/x/tools/gopls@v0.12.0 h1:O8KGdGuvu3YmAwim3KYmV2l20Cce5VMS74LayO2cDw8= github.com/BurntSushi/toml@v1.2.1 h1:9F2/+DoOYIOksmaJFPw1tGFy1eDnIJXg+UHjuD8lTak= github.com/google/go-cmp@v0.5.9 h1:O2Tfq5qg4qc4AmwVlvv0oLiVAGB7enBSJ2x2DqQFi38= github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0= golang.org/x/exp@v0.0.0-20220722155223-a9213eeb770e h1:+WEEuIdZHnUeJJmEUjyYC2gfUMj69yZXw17EnHg/otA= golang.org/x/exp/typeparams@v0.0.0-20221212164502-fae10dda9338 h1:2O2DON6y3XMJiQRAS1UWU+54aec2uopH3x7MAiqGW6Y= golang.org/x/mod@v0.10.0 h1:lFO9qtOdlre5W1jxS3r/4szv2/6iXxScdzjoBMXNhYk= golang.org/x/sync@v0.2.0 h1:PUR+T4wwASmuSTYdKjYHI5TD22Wy5ogLU5qZCOLxBrI= golang.org/x/sys@v0.8.0 h1:EBmGv8NaZBZTWvrbjNoL6HVt+IVy3QDQpJs7VRIw3tU= golang.org/x/text@v0.9.0 h1:2sjJmO8cDvYveuX97RDLsxlyUxLl+GHoLxBiRdHllBE= golang.org/x/tools@v0.9.2-0.20230524171317-188b785caf35 h1:B5e02cBXQWRAs5SloauCQ9RXMKeqz96eIBJ3W9Ofy+U= golang.org/x/vuln@v0.0.0-20230110180137-6ad3e3d07815 h1:A9kONVi4+AnuOr1dopsibH6hLi1Huy54cbeJxnq4vmU= honnef.co/go/tools@v0.4.2 h1:6qXr+R5w+ktL5UkwEbPp+fEvfyoMPche6GkOpGHZcLc= mvdan.cc/gofumpt@v0.4.0 h1:JVf4NN1mIpHogBj7ABpgOyZc65/UUOkKQFkoURsz4MM= mvdan.cc/xurls/v2@v2.4.0 h1:tzxjVAj+wSBmDcF6zBB7/myTy3gX9xvi8Tyr28AuQgc= go: go1.19.2

go env

GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/Users/kaurkerdevourer/Library/Caches/go-build" GOENV="/Users/kaurkerdevourer/Library/Application Support/go/env" GOEXE="" GOEXPERIMENT="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOINSECURE="" GOMODCACHE="/Users/kaurkerdevourer/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="darwin" GOPATH="/Users/kaurkerdevourer" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64" GOVCS="" GOVERSION="go1.19.2" GCCGO="gccgo" GOAMD64="v1" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="/Users/kaurkerdevourer/Desktop/git/repo/go.mod" GOWORK="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/gn/x8n96lv93171yc5pcv09r02w0000gn/T/go-build509356644=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Tried to open VSCode

What did you expect to see?

Normal working VSCode

What did you see instead?

Nothing works, can't run tests, can't go to definition. In console I can see panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x58 pc=0x1007e49f1]

goroutine 111 [running]: golang.org/x/tools/gopls/internal/lsp/cache.(snapshot).Analyze(0xc0006a6000, {0x100d6a3c0, 0xc00045a870}, {0xc0004bec00, 0x3f}, {0xc001cdf000, 0xc9, 0x100819dc5?}) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools/gopls@v0.12.0/internal/lsp/cache/analysis.go:229 +0x491 golang.org/x/tools/gopls/internal/lsp/source.Analyze({0x100d6a3c0, 0xc00045a870}, {0x100d76cd8, 0xc0006a6000}, {0xc0004bec00, 0x3f}, 0x1) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools/gopls@v0.12.0/internal/lsp/source/diagnostics.go:48 +0x264 golang.org/x/tools/gopls/internal/lsp.(Server).codeAction(0x10095a8e0?, {0x100d6a318?, 0xc0001f2540?}, 0xc0002d6700) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools/gopls@v0.12.0/internal/lsp/code_action.go:206 +0x16b8 golang.org/x/tools/gopls/internal/lsp.(*Server).CodeAction(0xc000346000?, {0x100d6a318?, 0xc0001f2540?}, 0x10095a8e0?) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools/gopls@v0.12.0/internal/lsp/server_gen.go:16 +0x25 golang.org/x/tools/gopls/internal/lsp/protocol.serverDispatch({0x100d6a318, 0xc0001f2540}, {0x100d7a110, 0xc0001e64e0}, 0xc00045a330, {0x100d6a5f0, 0xc0001f2440}) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools/gopls@v0.12.0/internal/lsp/protocol/tsserver.go:237 +0x1f57 golang.org/x/tools/gopls/internal/lsp/protocol.ServerHandler.func1({0x100d6a318, 0xc0001f2540}, 0xc00045a330, {0x100d6a5f0, 0xc0001f2440}) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools/gopls@v0.12.0/internal/lsp/protocol/protocol.go:157 +0x90 golang.org/x/tools/gopls/internal/lsp/lsprpc.handshaker.func1({0x100d6a318, 0xc0001f2540}, 0xc00045a330, {0x100d6a5f0?, 0xc0001f2440?}) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools/gopls@v0.12.0/internal/lsp/lsprpc/lsprpc.go:519 +0xa39 golang.org/x/tools/internal/jsonrpc2.MustReplyHandler.func1({0x100d6a318, 0xc0001f2540}, 0xc000216e70, {0x100d6a5f0?, 0xc0001f2440?}) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools@v0.9.2-0.20230524171317-188b785caf35/internal/jsonrpc2/handler.go:35 +0xf6 golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1.2() /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools@v0.9.2-0.20230524171317-188b785caf35/internal/jsonrpc2/handler.go:103 +0xa3 created by golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1 /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools@v0.9.2-0.20230524171317-188b785caf35/internal/jsonrpc2/handler.go:100 +0x20a

Editor and settings

VSCODE { "security.workspace.trust.untrustedFiles": "open", "files.autoSave": "afterDelay", "editor.formatOnSave": false, "[go]": { "editor.formatOnSave": false }, "[python]": { "editor.formatOnType": true }, "go.toolsManagement.autoUpdate": false, "dev.containers.gitCredentialHelperConfigLocation": "none", "dev.containers.copyGitConfig": false, "cmake.configureOnOpen": true, "cmake.buildDirectory": "/tmp/vscode-build", "C_Cpp.intelliSenseEngine": "disabled", "window.zoomLevel": -1, "gopls": {

},

}

Logs

https://cs.opensource.google/go/x/tools/+/refs/tags/gopls/v0.12.0:gopls/internal/lsp/cache/analysis.go;l=228 "result" can be nil, so .Err will result in panic

[KaurkerDevourer]

Also, worth to mention, this panic (.Err on nil) happens a lot in console with different ways.

[KaurkerDevourer]

In 0.11.0 version all was ok, and today I successfully returned 0.11.0 version - everything works fine. Something wrong with 12 version of gopls

[findleyr]

Thanks very much for the report. We'll fix this panic.

CC @adonovan

[gopherbot]

Change https://go.dev/cl/500055 mentions this issue: gopls/internal/lsp/cache: add assertions

[adonovan]

@KaurkerDevourer, would you mind installing the latest prerelease which contains additional assertions for this issue, and report whether the crashes you see have changed?

$ go install golang.org/x/tools/gopls@v0.12.1-pre.1

I don't expect the change to fix the bug, but it should give us more information. Thanks!

[adonovan]

Also, if you're able to reproduce this on an open-source project, please tell us, as that would make it much easier to diagnose and fix. Thanks.

[KaurkerDevourer]

Hello. Sorry, just noticed updates on this issue. Actually, yes, now you got some more info =)

panic: analyzeSummary.Actions["asmdecl"] = (nil, false); got map[ctrlflow:0xc0013ef6e0 printf:0xc0013ef740] (#60551) goroutine 164 [running]: golang.org/x/tools/gopls/internal/lsp/cache.(snapshot).Analyze(0xc0005fc000, {0x100d69fa0, 0xc000561410}, {0xc00082ef00, 0x4e}, {0xc001d3d000, 0xc9, 0x100819805?}) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools/gopls@v0.12.1-pre.1/internal/lsp/cache/analysis.go:221 +0x965 golang.org/x/tools/gopls/internal/lsp/source.Analyze({0x100d69fa0, 0xc000561410}, {0x100d768b8, 0xc0005fc000}, {0xc00082ef00, 0x4e}, 0x1) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools/gopls@v0.12.1-pre.1/internal/lsp/source/diagnostics.go:48 +0x264 golang.org/x/tools/gopls/internal/lsp.(Server).codeAction(0x10095a360?, {0x100d69ef8?, 0xc00040e000?}, 0xc0002b6fc0) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools/gopls@v0.12.1-pre.1/internal/lsp/code_action.go:206 +0x16b8 golang.org/x/tools/gopls/internal/lsp.(*Server).CodeAction(0xc000604200?, {0x100d69ef8?, 0xc00040e000?}, 0x10095a360?) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools/gopls@v0.12.1-pre.1/internal/lsp/server_gen.go:16 +0x25 golang.org/x/tools/gopls/internal/lsp/protocol.serverDispatch({0x100d69ef8, 0xc00040e000}, {0x100d79cf0, 0xc00030a0d0}, 0xc000560f00, {0x100d6a1d0, 0xc00012be80}) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools/gopls@v0.12.1-pre.1/internal/lsp/protocol/tsserver.go:237 +0x1f57 golang.org/x/tools/gopls/internal/lsp/protocol.ServerHandler.func1({0x100d69ef8, 0xc00040e000}, 0xc000560f00, {0x100d6a1d0, 0xc00012be80}) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools/gopls@v0.12.1-pre.1/internal/lsp/protocol/protocol.go:157 +0x90 golang.org/x/tools/gopls/internal/lsp/lsprpc.handshaker.func1({0x100d69ef8, 0xc00040e000}, 0xc000560f00, {0x100d6a1d0?, 0xc00012be80?}) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools/gopls@v0.12.1-pre.1/internal/lsp/lsprpc/lsprpc.go:519 +0xa39 golang.org/x/tools/internal/jsonrpc2.MustReplyHandler.func1({0x100d69ef8, 0xc00040e000}, 0xc000012b88, {0x100d6a1d0?, 0xc00012be80?}) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools@v0.9.4-0.20230601215739-41a7dc76dd8f/internal/jsonrpc2/handler.go:35 +0xf6 golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1.2() /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools@v0.9.4-0.20230601215739-41a7dc76dd8f/internal/jsonrpc2/handler.go:103 +0xa3 created by golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1 /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools@v0.9.4-0.20230601215739-41a7dc76dd8f/internal/jsonrpc2/handler.go:100 +0x20a

Sadly, project is not public.

But above the error I can see 2023/06/13 10:49:34 go/packages.Load #1: updating metadata for 251 packages 2023/06/13 10:49:34 computing the shared import graph: import failed for "vendor/golang.org/x/crypto/chacha20poly1305": internal error while importing "vendor/golang.org/x/crypto/chacha20poly1305" (conflicting names chacha20poly1305 and server for package "vendor/golang.org/x/crypto/chacha20poly1305"); please report an issue

Seems like now panic is expected. https://cs.opensource.google/go/x/tools/+/refs/tags/gopls/v0.12.1-pre.1:gopls/internal/lsp/cache/analysis.go;l=221

Every panic has the exact same - "asmdecl", ctrlflow, printf

[adonovan]

Thanks @KaurkerDevourer! I'm still looking into this, but it's worth knowing that we just made a significant reorganization of the analysis driver (primarily a performance optimization), and it looks like it touched many of the same elements that I think are likely responsible for the bug you reported here. So you might want to try building the very latest gopls@master and see if it makes any difference. (How often does the problem strike? How long would it take for you to notice whether today's change had any benefit?)

[adonovan]

The "conflicting names" log message is a separate issue; I've filed https://github.com/golang/go/issues/60904.

[adonovan]

We (@findleyr and I) have still had no luck trying to come up with a hypothesis for the main issue here, and not for lack of trying: every piece of the old implementation looks sound. Unsatisfying though it is, we recommend that you try building from master (or using today's https://github.com/golang/tools/releases/tag/gopls%2Fv0.12.3-pre.1) and see if the problem persists. Please do let us know what you find.

[findleyr]

If this no longer occurs in gopls@v0.12.4, I think we should close. This logic has been largely rewritten.

@KaurkerDevourer could you please go install golang.org/x/tools/gopls@latest and let us know if you still encounter this bug?

[KaurkerDevourer]

Request textDocument/semanticTokens/full failed. Message: semantictokens are disabled Code: 0 panic: analyzeSummary.Actions["asmdecl"] = (nil, false); got map[ctrlflow:0xc005fb2240 inspect:0xc005fb22a0 printf:0xc005fb2300] (#60551)

goroutine 5245 [running]: golang.org/x/tools/gopls/internal/lsp/cache.(snapshot).Analyze(0x0, {0x100d69c20, 0xc0054e89c0}, 0xc0052ed350, {0xc004856000, 0xc9, 0x203001?}) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools/gopls@v0.12.4/internal/lsp/cache/analysis.go:363 +0x1146 golang.org/x/tools/gopls/internal/lsp/source.Analyze({0x100d69c20, 0xc0054e89c0}, {0x100d76538, 0xc009360180}, 0xc007124af0?, 0x1) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools/gopls@v0.12.4/internal/lsp/source/diagnostics.go:48 +0x255 golang.org/x/tools/gopls/internal/lsp.(Server).codeAction(0x100959ca0?, {0x100d69b78?, 0xc007a68f00?}, 0xc0004f7f80) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools/gopls@v0.12.4/internal/lsp/code_action.go:206 +0x16e5 golang.org/x/tools/gopls/internal/lsp.(*Server).CodeAction(0xc000596200?, {0x100d69b78?, 0xc007a68f00?}, 0x100959ca0?) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools/gopls@v0.12.4/internal/lsp/server_gen.go:16 +0x25 golang.org/x/tools/gopls/internal/lsp/protocol.serverDispatch({0x100d69b78, 0xc007a68f00}, {0x100d79970, 0xc0000beea0}, 0xc0054e8780, {0x100d69e50, 0xc007a68e80}) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools/gopls@v0.12.4/internal/lsp/protocol/tsserver.go:237 +0x1f57 golang.org/x/tools/gopls/internal/lsp/protocol.ServerHandler.func1({0x100d69b78, 0xc007a68f00}, 0xc0054e8780, {0x100d69e50, 0xc007a68e80}) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools/gopls@v0.12.4/internal/lsp/protocol/protocol.go:157 +0x90 golang.org/x/tools/gopls/internal/lsp/lsprpc.handshaker.func1({0x100d69b78, 0xc007a68f00}, 0xc0054e8780, {0x100d69e50?, 0xc007a68e80?}) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools/gopls@v0.12.4/internal/lsp/lsprpc/lsprpc.go:519 +0xa39 golang.org/x/tools/internal/jsonrpc2.MustReplyHandler.func1({0x100d69b78, 0xc007a68f00}, 0xc002bf2450, {0x100d69e50?, 0xc007a68e80?}) /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools@v0.10.1-0.20230622221742-0622ad2359a7/internal/jsonrpc2/handler.go:35 +0xf6 golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1.2() /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools@v0.10.1-0.20230622221742-0622ad2359a7/internal/jsonrpc2/handler.go:103 +0xa3 created by golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1 /Users/kaurkerdevourer/go/pkg/mod/golang.org/x/tools@v0.10.1-0.20230622221742-0622ad2359a7/internal/jsonrpc2/handler.go:100 +0x20a

[adonovan]

This is very strange. There's clearly some confusion about the set of analyzers associated with a root node: the final loop of (*snapshot).Analyze expects the enabled set, but instead gets a summary of actions of only the facty subset. But the logic looks sound, even after hours of staring at it and adding assertions. I wonder what is special about this workspace that is triggering the assertion failure.

[adonovan]

Related:

• 66732

[findleyr]

Still no idea what this is. Though the analysis logic has been significantly reworked, I'm not sure if this is fixed. Moving to v0.18.0.