Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/gopls: gopls --remote=auto can sometimes exit 2 during nvim shutdown (Client 1 quit with exit code 2 and signal 0) #51252

Open
jdstrand opened this issue Feb 18, 2022 · 3 comments
Labels
gopls Issues related to the Go language server, gopls. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@jdstrand
Copy link

jdstrand commented Feb 18, 2022

ATTENTION: Please answer these questions BEFORE submitting your issue. Thanks!

What did you do?

I changed my nvim (0.6.1) lsp configuration to start gopls with --remote=auto. If I open a go file with nvim I can see the gopls daemon listening and when I exit cleanly (eg, with :q), I see the terminal prompt and the daemon goes away after 1 minute (great; this is all as per design). If instead I open two different go files in two different terminals (ie, the first starts the daemon and connects while the second connects to the daemon; so far so good), then when I close the first nvim (eg, :q), I see:

$ nvim ./path/to/foo.go
Client 1 quit with exit code 2 and signal 0
$

This message is coming from https://github.com/neovim/neovim/blob/master/runtime/lua/vim/lsp.lua#L854 which is simply noticing that gopls exited non-zero and reporting it so the issue is that gopls is exiting 2 for some reason. Curiously:

  • open nvim 1, then open nvim 2, closing nvim 2 usually results in gopls exiting 0 (no message), but closing nvim 1 consistently has gopls exiting 2 (message)
  • open nvim 1, then open nvim 2, closing nvim 1 consistently results in gopls exiting 2 and then closing nvim 2 consistently has gopls exit 2
  • opening 3 nvims and closing any of them has gopls consistently exit with 2

In terms of setup, I use nvim 0.6.1 on Linux and I followed https://github.com/golang/tools/blob/master/gopls/doc/vim.md#custom-configuration with my custom setup being simply:

lua <<EOF
  lspconfig = require "lspconfig"
  lspconfig.gopls.setup {
    cmd = {"gopls", "--remote=auto"}
  }
EOF

(before I was just using lspconfig.gopls.setup {})

WORKAROUND: while I don't care for this since IME the fix should be in gopls and the workaround affects all lsp servers, not just gopls, one can adjust /usr/share/nvim/runtime/lua/vim/lsp.lua (adjust for your installation) to use:

@@ -790,7 +790,7 @@
       client_ids[client_id] = nil
     end
 
-    if code ~= 0 or (signal ~= 0 and signal ~= 15) then
+    if (code ~= 0 and code ~= 2) or (signal ~= 0 and signal ~= 15) then
       local msg = string.format("Client %s quit with exit code %s and signal %s", client_id, code, signal)
       vim.schedule(function()
         vim.notify(msg, vim.log.levels.WARN)

What did you expect to see?

No output from nvim during a clean exit from any number of nvim connections.

What did you see instead?

With multiple open nvims to go files, usually see Client 1 quit with exit code 2 and signal 0.

Build info

golang.org/x/tools/gopls v0.7.4
    golang.org/x/tools/gopls@v0.7.4 h1:hw8cpqjio1iMwIKbbDkG3MeW4l8R9dY/yqOHqv7HImA=
    github.com/BurntSushi/toml@v0.4.1 h1:GaI7EiDXDRfa8VshkTj7Fym7ha+y8/XxIgD2okUIjLw=
    github.com/google/go-cmp@v0.5.6 h1:BKbKCqvP6I+rmFHt06ZmyQtvB8xAkWdhFyr0ZUNZcxQ=
    github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0=
    golang.org/x/mod@v0.5.1 h1:OJxoQ/rynoF0dcCdI7cLPktw/hR2cueqYfjm43oqK38=
    golang.org/x/sync@v0.0.0-20210220032951-036812b2e83c h1:5KslGYwFpkhGh+Q16bwMP3cOontH8FOep7tGV86Y7SQ=
    golang.org/x/sys@v0.0.0-20211019181941-9d821ace8654 h1:id054HUawV2/6IGm2IV8KZQjqtwAOo2CYlOToYqa0d0=
    golang.org/x/text@v0.3.7 h1:olpwvP2KacW1ZWvsR7uQhoyTYvKAupfQrRGBFM352Gk=
    golang.org/x/tools@v0.1.9-0.20211209172050-90a85b2969be h1:JRBiPXZpZ1FsceyPRRme0vX394zXC3xlhqu705k9nzM=
    golang.org/x/xerrors@v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
    honnef.co/go/tools@v0.2.1 h1:/EPr//+UMMXwMTkXvCCoaJDq8cpjMO80Ou+L4PDo2mY=
    mvdan.cc/gofumpt@v0.1.1 h1:bi/1aS/5W00E2ny5q65w9SnKpWEF/UIOqDYBILpo9rA=
    mvdan.cc/xurls/v2@v2.3.0 h1:59Olnbt67UKpxF1EwVBopJvkSUBmgtb468E4GVWIZ1I=
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Feb 18, 2022
@gopherbot gopherbot added this to the Unreleased milestone Feb 18, 2022
@findleyr findleyr added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 18, 2022
@findleyr findleyr modified the milestones: Unreleased, gopls/v0.8.1 Feb 18, 2022
@findleyr
Copy link
Contributor

Thank you for the detailed report -- I'll investigate for v0.8.1.

@mvdan
Copy link
Member

mvdan commented Jun 18, 2022

I am toying with replacing vim+govim for neovim and its native LSP support, still using gopls the same as I did before - with -remote=auto. I started running into this issue :)

I dug up the neovim LSP client logs, and saw this right when I :q the editor that causes the error:

[ERROR][2022-06-18 20:48:17] .../vim/lsp/rpc.lua:420	"rpc"	"gopls"	"stderr"	"gopls: remote disconnected: failed reading header line: EOF\n"

It seems like the server's "read incoming messages" loop is never allowed to finish, and does not treat EOF errors in any special way, so when the client hangs up, it gets upset.

I'm going to send a CL to patch that up in the simplest way in the jsonrpc packages, and perhaps Rob can tell me whether that approach is too naive :) I don't think we want the LSP client to send a shutdown request in this scenario, because with -remote=auto, I want gopls to remain alive for a little while - in my case, I've set the remote timeout to 5m.

@mvdan
Copy link
Member

mvdan commented Jun 28, 2022

My fix at https://go-review.googlesource.com/c/tools/+/413194 was admittedly too naive, but FYI @alandonovan @bcmills I'm more than happy to test a newer gopls master once the related fixes land to help confirm whether or not the bug is fixed.

For the time being, I can live with the error output :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gopls Issues related to the Go language server, gopls. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

4 participants