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

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`

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?

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.

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

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

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

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

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

@rahukarmore Looks like at least, gopls doesn't crash according to your last comment (#66414 (comment)).
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.

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