x/tools/gopls: crash in View.Options

[TristanSpeakEasy]

gopls version: v0.12.4 (go1.20.5)
gopls flags:
update flags: proxy
extension version: 0.39.0
go version: 1.20.5
environment: Visual Studio Code linux
initialization error: undefined
issue timestamp: Wed, 12 Jul 2023 01:49:36 GMT
restart history:
Mon, 10 Jul 2023 06:01:44 GMT: activation (enabled: true)
Wed, 12 Jul 2023 00:24:00 GMT: manual (enabled: true)
Wed, 12 Jul 2023 00:38:53 GMT: manual (enabled: true)
Wed, 12 Jul 2023 00:49:51 GMT: manual (enabled: true)
Wed, 12 Jul 2023 01:15:40 GMT: manual (enabled: true)
Wed, 12 Jul 2023 01:42:51 GMT: manual (enabled: true)

ATTENTION: PLEASE PROVIDE THE DETAILS REQUESTED BELOW.

Describe what you observed.

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x38 pc=0xc3be7c]

goroutine 30894 [running]:
golang.org/x/tools/gopls/internal/lsp/cache.(*View).Options(0x115b080%3F)
	  view.go:405  0x3c
golang.org/x/tools/gopls/internal/lsp/cache.(*Session).DidModifyFiles(0xc0001229c0, {0x115b080, 0xc0037fd8f0}, {0xc00df32000, 0xcb, 0x0%3F})
	  session.go:455  0x1085
golang.org/x/tools/gopls/internal/lsp.(*Server).didModifyFiles(0xc00039a4e0, {0x115b080%3F, 0xc0037fd8f0}, {0xc00e7ceb90, 0x1, 0x1}, 0x2)
	  text_synchronization.go:273  0x513
golang.org/x/tools/gopls/internal/lsp.(*Server).didChangeWatchedFiles(0xd5d700%3F, {0x115b080%3F, 0xc00442d860%3F}, 0xc00680fc08)
	  text_synchronization.go:189  0x315
golang.org/x/tools/gopls/internal/lsp.(*Server).DidChangeWatchedFiles(0xc00ddd6000%3F, {0x115b080%3F, 0xc00442d860%3F}, 0xd5d700%3F)
	  server_gen.go:60  0x25
golang.org/x/tools/gopls/internal/lsp/protocol.serverDispatch({0x115b080, 0xc00442d860}, {0x116bcd0, 0xc00039a4e0}, 0xc0037fd830, {0x115b2e8, 0xc00442d7a0})
	  tsserver.go:646  0x5444
golang.org/x/tools/gopls/internal/lsp/protocol.ServerHandler.func1({0x115b080, 0xc00442d860}, 0xc0037fd830, {0x115b2e8, 0xc00442d7a0})
	  protocol.go:157  0x90
golang.org/x/tools/gopls/internal/lsp/lsprpc.handshaker.func1({0x115b080, 0xc00442d860}, 0xc0037fd830, {0x115b2e8%3F, 0xc00442d7a0%3F})
	  lsprpc.go:519  0x9f9
golang.org/x/tools/internal/jsonrpc2.MustReplyHandler.func1({0x115b080, 0xc00442d860}, 0xc00d5081c8, {0x115b2e8%3F, 0xc00442d7a0%3F})
	  handler.go:35  0xf6
golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1.2()
	  handler.go:103  0xa3
created by golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1
	  handler.go:100  0x20a
[Error - 11:49:23 AM] 

OPTIONAL: If you would like to share more information, you can attach your complete gopls logs.

NOTE: THESE MAY CONTAIN SENSITIVE INFORMATION ABOUT YOUR CODEBASE.
DO NOT SHARE LOGS IF YOU ARE WORKING IN A PRIVATE REPOSITORY.

<OPTIONAL: ATTACH LOGS HERE>

[hyangah]

Thanks for the report! @TristanSpeakEasy
We will transfer this to the gopls issue tracker.

[findleyr]

Hi @TristanSpeakEasy I see also from your activation history that you had manually restarted the language server several times. Could you share why you had to do that?

[findleyr]

This is really strange. The crash indicates that a view in Session.views is nil. Granted, there is some tricky logic updating that field when views are removed or updated, but I've gone through that logic twice now (and once with @adonovan) and it appears sound to me.

@TristanSpeakEasy this is not reproducible, right?

[findleyr]

Moving this to [email protected], as I don't think we'll be able to figure this out in time for the v0.12.5 release, this crash must by very unlikely, and there's no way to avoid the crash even if we don't understand it: if Session.views contains a nil element, the game is over.

[TristanSpeakEasy]

So I have only seen the crash once so far, but I do get a lot of other weird behaviour with our work flow.

Basically we develop a SDK Generation product and so we are quite often going through a flow of deleting and regenerating an entire Go project over and over again.

I generally have to restart the Go language server after each generation as it stops providing any intellisense after a generation.

[findleyr]

I generally have to restart the Go language server after each generation as it stops providing any intellisense after a generation.

Thanks for the explanation. Is this product open-source? I'd be interested in debugging.

[TristanSpeakEasy]

It’s not open source but it is available to use freely at the moment. It is a SDK generator from an OpenAPI document.

We have a CLI tool that can be downloaded and used to generate a Go project over and over again https://speakeasyapi.dev/docs/speakeasy-cli/getting-started/ which causes the exact same behaviour if the go project is open in VSCode when you are regenerating

[gopherbot]

Change https://go.dev/cl/526159 mentions this issue: gopls/internal/lsp: move options into the snapshot