The gopls server crashed when upgrade vscode-go to 0.10.0

[gotoxu]

I just upgraded vscode-go to 0.10.0, but once I open the project I found that vscode has been reporting gopls crashed:

The gopls server crashed 5 times in the last 3 minutes. The server will not be restarted.

It works fine in version 0.9.2, or change gopls to bingo can also return to normal.

This is my vscode-go related configuration:

{
    "go.formatTool": "goimports",
    "go.languageServerFlags": [
        "-trace"
    ],
    "go.languageServerExperimentalFeatures": {
        "format": true,
        "autoComplete": true,
        "rename": true,
        "goToDefinition": true,
        "hover": true,
        "signatureHelp": true,
        "goToTypeDefinition": true,
        "goToImplementation": true,
        "documentSymbols": true,
        "workspaceSymbols": true,
        "findReferences": true
    },
    "go.useLanguageServer": true,
}

[stamblerre]

Can you try switching the flag to -rpc.trace? I think we switched that one.

[gotoxu]

@stamblerre Yes, it works! So the README.md file needs to be updated.

Below are the settings you can use to control the use of the language server. You need to reload the VS Code window for any changes in these settings to take effect.

• Set go.useLanguageServer to true to enable the use of language server
• Use the setting go.languageServerExperimentalFeatures to control which features do you want to be powered by the language server.
• Set "go.languageServerFlags": ["-trace"] to collect traces in the output panel.
• Set "go.languageServerFlags": ["-trace", "-logfile", "path to a text file that exists"] to collect traces in a log file.

[ramya-rao-a]

Thanks for reporting @gotoxu!

@stamblerre Was that intentional? Do you plan to keep that or move back to -trace at any point?

[stamblerre]

@ramya-rao-a: Yes, it was. I think we will likely stick with -rpc.trace for now.

Perhaps we could add some additional handling for invalid flags so that they don't completely crash the server, though I'm not sure how that would look. I expect it would have to be in the extension, so that it could notify the user that they've passed an incorrect flag.

[ramya-rao-a]

We can't handle all invalid flags, but we definitely can handle this one.
Updated the extension to pass -rpc.trace to gopls if user has -trace with d0eed08

[ramya-rao-a]

The fix is out in the update I just released (0.10.1)

Thanks again for reporting @gotoxu!

[wolfeidau]

I am getting this error as well but on 0.10.1 😞

The gopls server crashed 5 times in the last 3 minutes. The server will not be restarted.

Golang version is.

$ go version
go version go1.12.4 linux/amd64

[stamblerre]

@wolfeidau: What flags are you passing to the language server?

[wolfeidau]

@stamblerre I didn't change or update any settings for gopls, just did the upgrade to vscode-go.

Ended up cleaning out go modules cache to fix this, not sure what was up.

[stamblerre]

@wolfeidau: Glad it's working now, thanks for reporting this. Please file an issue here if you encounter this again.

[adk9]

I am also getting this error on 0.10.2.

VS Code version is:

Version: 1.33.1
Commit: 51b0b28134d51361cf996d2f0a1c698247aeabd8
Date: 2019-04-11T08:20:22.771Z
Electron: 3.1.6
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Linux x64 5.0.0-13-generic

golang version is:

$ go version
go version go1.12 linux/amd64

Cleaned the modules cache and reinstalled the extension, but neither helped. Adding the -rpc.trace flag doesn't print anything in the output panel. How can I debug what's going on?

[stamblerre]

Do you see "gopls" under the list of "Tasks" in the output panel?

[adk9]

@stamblerre, Thanks, I see it now.

I was able to get a stacktrace of the crash:

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

goroutine 6 [running]:
golang.org/x/tools/internal/lsp/source.(*IdentifierInfo).Hover(0x0, 0x0, 0x819280, 0xc4200b6120, 0x81a140, 0xc42c5485a0)
	golang.org/x/tools/internal/lsp/source/definition.go:50 +0x76
golang.org/x/tools/internal/lsp.(*server).Hover(0xc420074900, 0x819dc0, 0xc4343e4400, 0xc4343e18c0, 0xc4343e18c0, 0x0, 0x0)
	golang.org/x/tools/internal/lsp/server.go:225 +0x185
golang.org/x/tools/internal/lsp/protocol.serverHandler.func1(0x819dc0, 0xc4343e4400, 0xc4200e53b0, 0xc4343e1880)
	golang.org/x/tools/internal/lsp/protocol/server.go:211 +0xd6d
golang.org/x/tools/internal/jsonrpc2.(*Conn).run(0xc4200e53b0, 0x819e00, 0xc420012170, 0xc420045fc8, 0x5f54e3)
	golang.org/x/tools/internal/jsonrpc2/jsonrpc2.go:327 +0x5d3
golang.org/x/tools/internal/jsonrpc2.NewConn.func4(0xc4200e53b0, 0x819e00, 0xc420012170)
	golang.org/x/tools/internal/jsonrpc2/jsonrpc2.go:107 +0x3f
created by golang.org/x/tools/internal/jsonrpc2.NewConn
	golang.org/x/tools/internal/jsonrpc2/jsonrpc2.go:106 +0x329

Let me know if you want me to create a new issue.

[stamblerre]

@adk9: what version of gopls are you currently using? There is no longer a golang.org/x/tools/internal/lsp/source/definition.go file, so I imagine this bug is likely already resolved. gopls moves quite quickly, so it is worth updating the binary regularly.

[adk9]

I'm not sure what version I was running but updating/reinstalling Go tools seems to have fixed this and a host of other issues I was seeing.

1. Ctrl-Shift-P
2. Go: Install/Update Tools

Thanks!