x/tools/gopls: crash in buildPackageHandle (nil packageHandle)

[rahukarmore]

When I try to use ctrl + click in VS Code, it doesn't work. I suspect there's an error.

gopls version: v0.15.2/go1.20.2
gopls flags:
update flags: proxy
extension version: 0.41.2
environment: Visual Studio Code linux
initialization error: undefined
issue timestamp: Tue, 19 Mar 2024 13:29:56 GMT
restart history:
Tue, 19 Mar 2024 13:29:44 GMT: activation (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=0xe8 pc=0xa800df]

goroutine 4057 [running]:
golang.org/x/tools/gopls/internal/cache.(*packageHandleBuilder).getOneTransitiveRefLocked(0xc003c7e100, {0xc004b398c0%3F, {0xc0006675e8%3F, 0x16%3F}})
	  check.go:1088  0x2df
golang.org/x/tools/gopls/internal/cache.(*packageHandleBuilder).getTransitiveRefs(0xc003c7e100, {0xc000c1bc80%3F, 0x4%3F})
	  check.go:1026  0x4ee
golang.org/x/tools/gopls/internal/cache.(*packageHandleBuilder).evaluatePackageHandle(0xc003c7e100, 0x66%3F, 0xc0046a6870)
	  check.go:1206  0x2e5
golang.org/x/tools/gopls/internal/cache.(*packageHandleBuilder).buildPackageHandle(0xc003c7e100, {0x124ce30%3F, 0xc0046a7180%3F}, 0xc0046a6870)
	  check.go:1138  0x4cf
golang.org/x/tools/gopls/internal/cache.(*Snapshot).getPackageHandles.func2.1()
	  check.go:932  0xed
golang.org/x/sync/errgroup.(*Group).Go.func1()
	  errgroup.go:78  0x64
created by golang.org/x/sync/errgroup.(*Group).Go
	  errgroup.go:75  0xa5

gopls stats -anon

gopls stats -anon failed after 1191 ms. Please check if gopls is killed by OS.

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>

[findleyr]

Hi, thanks for the report. Is this crash reproducible?

[rahukarmore]

yes it is

`[Error - 9:40:22 PM] Request textDocument/inlayHint failed.
Message: getting file for InlayHint: no package metadata for file file:///home/workspace/src/gitlab.abcExample.com/platform/path/token_test.go
Code: 0
[Error - 9:40:22 PM] Request textDocument/inlayHint failed.
Message: getting file for InlayHint: no package metadata for file file:///home/workspace/src/gitlab.abcExample.com/platform/path//token_test.go
Code: 0
[Error - 9:40:22 PM] Request textDocument/inlayHint failed.
Message: getting file for InlayHint: no package metadata for file file:///home/workspace/src/gitlab.abcExample.com/platform/path/token_test.go
Code: 0
[Error - 9:40:22 PM] Request textDocument/inlayHint failed.
Message: getting file for InlayHint: no package metadata for file file:///home/workspace/src/gitlab.abcExample.com/platform/path/token_test.go
Code: 0
[Error - 9:40:22 PM] Request textDocument/semanticTokens/range failed.
Message: no package metadata for file file:///home/abc/token_test.go
Code: 0
[Error - 9:40:23 PM] 2024/03/19 21:40:23 warning: diagnostics failed: missing reachable package
snapshot=1
directory=file:///home/workspace/src/gitlab.myservice.com/plat/servce

[Info - 9:40:52 PM] 2024/03/19 21:40:52 background imports cache refresh starting

[Info - 9:40:52 PM] 2024/03/19 21:40:52 background refresh finished after 276.249817ms`

[findleyr]

Thanks. We'll investigate this crash.

Do you happen to be working in something that is open source, so that we may try to reproduce?

[findleyr]

Transferring to the Go repo, since this is a gopls issue. Tentatively assigning to the gopls/v0.16.0 milestone for mitigation. This crash would have been present since July, so it seems like it is probably rare. The fact that it is reproducible is interesting though.

If we can fully understand the crash, and the fix is safe (and, likely, if there are other reasons to cut a v0.15.3), we can consider fixing this in a patch release.

[rahukarmore]

@findleyr Do i need to set below value externally ?
GOWORK: GOPACKAGESDRIVER:})
(env overlay: map[])

[adonovan]

Building that binary on Linux and (I assume) amd64, the failing instruction appears to be the load of ph.refs, i.e. n.ph == nil.

golang.org/x/tools/gopls/internal/cache.(*packageHandleBuilder).getOneTransitiveRefLocked(0xc003c7e100, {0xc004b398c0%3F, {0xc0006675e8%3F, 0x16%3F}})
	  check.go:1088  0x2df

  check.go:1088         0xa7c153                488b942490000000        MOVQ 0x90(SP), DX         // unspill n                                                                                       
  check.go:1088         0xa7c15b                488b5210                MOVQ 0x10(DX), DX         // load n.ph                                                                       
  check.go:1088         0xa7c15f                488b9ae8000000          MOVQ 0xe8(DX), BX         // load ph.refs (SEGV)
  check.go:1088         0xa7c166                488d05931a4000          LEAQ 0x401a93(IP), AX                                                                                   
  check.go:1088         0xa7c16d                488b8c24c0000000        MOVQ 0xc0(SP), CX                                                                                       
  check.go:1088         0xa7c175                488b7c2468              MOVQ 0x68(SP), DI                                                                                       
  check.go:1088         0xa7c17a                e8016d99ff              CALL runtime.mapaccess1_faststr(SB)                                                                     

1088:		for _, sym2 := range n.ph.refs[sym.Name] {

I do wish gopls would report field offsets in Hover.

[Update: I nerdswiped myself: https://go.dev/cl/573076.]