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.

[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.]

[findleyr]

@adonovan yes, sorry I should have noted that aspect of my investigation. I agree that n.ph must be nil.

I didn't spot anything obvious in a quick scan, though could have missed something. My intuition is that there is some sort of cycle that isn't broken properly. We can perhaps create a patch release of gopls with a more useful panic message.

[findleyr]

@rahukarmore I'm not sure I understand. You should not need to set those values in general, unless you have to customize your environment. Generally speaking, if go build works, gopls should also work.

[rahukarmore]

@findleyr I appreciate your effort in the investigation. I was able to successfully run my service and create a build, even though my ctrl-click not working. please find the below details: gopls setting:

{
"diffEditor.ignoreTrimWhitespace": false,
"explorer.confirmDelete": false,
"window.zoomLevel": 1,
"go.toolsManagement.autoUpdate": true,
"git.openRepositoryInParentFolders": "never",
"gopls": {

    "ui.completion.usePlaceholders": true,
},
"[go]": {
    "editor.insertSpaces": false,
    "editor.formatOnSave": true,
    "editor.codeActionsOnSave": {
        "source.organizeImports": "explicit"
    }
}
}

Error while ctrl+click on some function:

[Error - 10:32:52 AM] Request textDocument/semanticTokens/range failed.
Message: semantictokens are disabled
Code: 0
[Info - 10:33:55 AM] 2024/03/21 10:33:55 background imports cache refresh starting

[Info - 10:33:55 AM] 2024/03/21 10:33:55 background refresh finished after 217.743815ms

[Info - 10:34:37 AM] 2024/03/21 10:34:37 background imports cache refresh starting

[Info - 10:34:38 AM] 2024/03/21 10:34:38 background refresh finished after 194.010131ms

in the meantime, I will try another approach.

[hyangah]

@rahukarmore Looks like at least, gopls doesn't crash according to your last comment (https://github.com/golang/go/issues/66414#issuecomment-2011229869). For the problem of ctrl+click not working (is it for 'go-to-definition'?), can you enable gopls tracing and see if there is any more info?

The following setting will enable tracing.

    "go.languageServerFlags": [ "-rpc.trace" ],

Look for message exchanges or suspicious error message around "textDocument/definition" rpcs.

[findleyr]

@rahukarmore could you also please try installing gopls with a more recent version of Go (preferably Go 1.22)?

[gopherbot]

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.)

[rahulkarmore]

@findleyr, the issue has been resolved. There were duplicate vendor files located in the same folder. Additionally, I updated the gopls to the latest version. Thank you so much for your support.