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: panic if subdirectories have files with different package #40043

Closed
sorenisanerd opened this issue Jul 4, 2020 · 4 comments
Closed
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@sorenisanerd
Copy link

sorenisanerd commented Jul 4, 2020

What did you do?

During some refactoring I added a comment and gopls crashed. I managed to narrow it down to the fact that I accidentally had two files in the same directory with different packages. I have autocompletion within comments enabled in VSCode.

It only seems to apply in subdirectories.

https://github.com/sorenh/gopls-bug has steps to reproduce. It wasn't 100% reproducible. It seemed to be most reliably reproducible if I opened VSCode afresh (with a directory tree as found in that repo) and then tried adding a comment.

What did you expect to see?

gopls shouldn't crash.

What did you see instead?

gopls panicked

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

goroutine 226 [running]:
golang.org/x/tools/internal/lsp/source.(*completer).populateCommentCompletions(0xc0001083c0, 0xeae040, 0xc000398f60, 0xc0004bbc40)
	/home/soren/src/tools/internal/lsp/source/completion.go:763 +0x363
golang.org/x/tools/internal/lsp/source.Completion(0xeae040, 0xc000398f60, 0xec39e0, 0xc0001be500, 0xeb1dc0, 0xc0003987e0, 0x4000000000000000, 0x4024000000000000, 0x0, 0x0, ...)
	/home/soren/src/tools/internal/lsp/source/completion.go:542 +0xb7e
golang.org/x/tools/internal/lsp.(*Server).completion(0xc0001be200, 0xeadfc0, 0xc0000823c0, 0xc000398f00, 0x0, 0x0, 0xc00052d290)
	/home/soren/src/tools/internal/lsp/completion.go:27 +0x6b9
golang.org/x/tools/internal/lsp.(*Server).Completion(0xc0001be200, 0xeadfc0, 0xc0000823c0, 0xc000398f00, 0xc000398f00, 0x0, 0x0)
	/home/soren/src/tools/internal/lsp/server_gen.go:24 +0x49
golang.org/x/tools/internal/lsp/protocol.serverDispatch(0xeadfc0, 0xc0000823c0, 0xecc440, 0xc0001be200, 0xc000433020, 0xeae200, 0xc000082340, 0x0, 0x0, 0xbfb85daf83e61bc2)
	/home/soren/src/tools/internal/lsp/protocol/tsserver.go:255 +0x2606
golang.org/x/tools/internal/lsp/protocol.ServerHandler.func1(0xeadfc0, 0xc0000823c0, 0xc000433020, 0xeae200, 0xc000082340, 0x0, 0x0)
	/home/soren/src/tools/internal/lsp/protocol/protocol.go:62 +0xc0
golang.org/x/tools/internal/lsp/lsprpc.handshaker.func1(0xeadfc0, 0xc0000823c0, 0xc000433020, 0xeae200, 0xc000082340, 0x0, 0x0)
	/home/soren/src/tools/internal/lsp/lsprpc/lsprpc.go:509 +0x43a
golang.org/x/tools/internal/jsonrpc2.MustReplyHandler.func1(0xeadfc0, 0xc0000823c0, 0xc0002de600, 0xeae200, 0xc000082340, 0x1ee9b0001ee8b, 0x1eea30001eea1)
	/home/soren/src/tools/internal/jsonrpc2/handler.go:35 +0xd3
golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1.2(0xc000040600, 0xc000326a50, 0xc0001aaca0, 0xeadfc0, 0xc0000823c0, 0xc0002de600, 0xeae200, 0xc000082340)
	/home/soren/src/tools/internal/jsonrpc2/handler.go:103 +0x86
created by golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1
	/home/soren/src/tools/internal/jsonrpc2/handler.go:100 +0x171
[Error - 12:14:22 AM] Connection to server got closed. Server will not be restarted.

Build info

golang.org/x/tools/gopls master
    golang.org/x/tools/gopls@(devel)
    github.com/BurntSushi/toml@v0.3.1 h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ=
    github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0=
    golang.org/x/mod@v0.2.0 h1:KU7oHjnv3XNWfa5COkzUifxZmxp1TyI7ImMXqFxLwvQ=
    golang.org/x/sync@v0.0.0-20190911185100-cd5d95a43a6e h1:vcxGaoTs7kV8m5Np9uUNQin4BrLOthgV7252N8V+FwY=
    golang.org/x/tools@v0.0.0-20200515220128-d3bf790afa53 => ../
    golang.org/x/xerrors@v0.0.0-20191204190536-9bdfabe68543 h1:E7g+9GITq07hpfrRu66IVDexMakfv52eLZ2CXBWiKr4=
    honnef.co/go/tools@v0.0.1-2020.1.4 h1:UoveltGrhghAA7ePc+e+QYDHXrBps2PqFZiHkGR/xK8=
    mvdan.cc/xurls/v2@v2.2.0 h1:NSZPykBXJFCetGZykLAxaL6SIpvbVy/UFEniIfHAa8A=

Go info

go version go1.13.8 linux/amd64

@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 Jul 4, 2020
@gopherbot
Copy link

Thank you for filing a gopls issue! Please take a look at the Troubleshooting guide, and make sure that you have provided all of the relevant information here.

@gopherbot gopherbot added this to the Unreleased milestone Jul 4, 2020
@sorenisanerd
Copy link
Author

https://github.com/golang/tools/blob/0cc1aa72b347c94167795784138aa2603df670ba/internal/lsp/source/completion.go#L757 returns nil, and then on line 763, we call obj.Name() which causes the panic. Adding a simple "if obj == nil { continue; }" would do the trick, but I'm pretty sure something more clever should happen if someone accidentally has a directory with files with different package names.

@sorenisanerd
Copy link
Author

Submitted a (naïve) patch for this problem: https://go-review.googlesource.com/c/tools/+/241019

@stamblerre stamblerre modified the milestones: Unreleased, gopls/v0.5.0 Jul 6, 2020
@gopherbot
Copy link

Change https://golang.org/cl/241019 mentions this issue: internal/lsp/source: handle nil pointer in comment completions

@stamblerre stamblerre modified the milestones: gopls/v0.5.0, gopls/v0.4.4 Jul 9, 2020
@golang golang locked and limited conversation to collaborators Jul 9, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

3 participants