x/tools/internal/lsp: crash on acme-lsp startup

[mariusae]

What version of Go are you using (go version)?

$ go version
go version go1.12.1 darwin/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/marius/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/marius/go"
GOPROXY=""
GORACE=""
GOROOT="/Users/marius/.gimme/versions/go1.12.1.darwin.amd64"
GOTMPDIR=""
GOTOOLDIR="/Users/marius/.gimme/versions/go1.12.1.darwin.amd64/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/6k/zldf6tdx42q2tdqd841n74gw0000gn/T/go-build782091440=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

When using acme-lsp with gopls, gopls crashes with a panic on startup.

What did you expect to see?

Not to panic.

What did you see instead?

A panic:

$ gopls -debug localhost:8081 -listen localhost:8080 serve  panic: runtime error: index out of range  goroutine 44 [running]: golang.org/x/tools/internal/lsp/cache.(*session).bestView(0xc00012f900, 0xc000026420, 0x57, 0x57, 0x1c5f300) 	/Users/marius/go/pkg/mod/golang.org/x/tools@v0.0.0-20190910165522-3cd124fa3ebb/internal/lsp/cache/session.go:172 +0x198 golang.org/x/tools/internal/lsp/cache.(*session).ViewOf(0xc00012f900, 0xc000026420, 0x57, 0x0, 0x0) 	/Users/marius/go/pkg/mod/golang.org/x/tools@v0.0.0-20190910165522-3cd124fa3ebb/internal/lsp/cache/session.go:140 +0xdd golang.org/x/tools/internal/lsp.(*Server).didOpen(0xc00021c2a0, 0x17e3180, 0xc000218780, 0xc000214740, 0x0, 0xc000236140) 	/Users/marius/go/pkg/mod/golang.org/x/tools@v0.0.0-20190910165522-3cd124fa3ebb/internal/lsp/text_synchronization.go:32 +0x183 golang.org/x/tools/internal/lsp.(*Server).DidOpen(0xc00021c2a0, 0x17e3180, 0xc000218780, 0xc000214740, 0xc000214740, 0x0) 	/Users/marius/go/pkg/mod/golang.org/x/tools@v0.0.0-20190910165522-3cd124fa3ebb/internal/lsp/server.go:134 +0x49 golang.org/x/tools/internal/lsp/protocol.serverHandler.Deliver(0x17f4d20, 0xc00021c2a0, 0x17e3180, 0xc000218780, 0xc0002187c0, 0x0, 0xc000048730) 	/Users/marius/go/pkg/mod/golang.org/x/tools@v0.0.0-20190910165522-3cd124fa3ebb/internal/lsp/protocol/tsserver.go:113 +0x1cc7 golang.org/x/tools/internal/jsonrpc2.(*Conn).Run.func1(0xc0001e0240, 0xc0002187c0, 0xc00021c300, 0x17e3180, 0xc000218780, 0x0, 0x0, 0xc0000adad0) 	/Users/marius/go/pkg/mod/golang.org/x/tools@v0.0.0-20190910165522-3cd124fa3ebb/internal/jsonrpc2/jsonrpc2.go:370 +0x13a created by golang.org/x/tools/internal/jsonrpc2.(*Conn).Run 	/Users/marius/go/pkg/mod/golang.org/x/tools@v0.0.0-20190910165522-3cd124fa3ebb/internal/jsonrpc2/jsonrpc2.go:354 +0x8d8 isotope=% !go gopls -debug localhost:8081 -listen localhost:8080 serve  panic: runtime error: index out of range  goroutine 38 [running]: golang.org/x/tools/internal/lsp/cache.(*session).bestView(0xc000129900, 0xc0001ba600, 0x57, 0x57, 0x1c5f300) 	/Users/marius/go/pkg/mod/golang.org/x/tools@v0.0.0-20190910165522-3cd124fa3ebb/internal/lsp/cache/session.go:172 +0x198 golang.org/x/tools/internal/lsp/cache.(*session).ViewOf(0xc000129900, 0xc0001ba600, 0x57, 0x0, 0x0) 	/Users/marius/go/pkg/mod/golang.org/x/tools@v0.0.0-20190910165522-3cd124fa3ebb/internal/lsp/cache/session.go:140 +0xdd golang.org/x/tools/internal/lsp.(*Server).didOpen(0xc000234240, 0x17e3180, 0xc000278240, 0xc000252040, 0x0, 0xc00024a1e0) 	/Users/marius/go/pkg/mod/golang.org/x/tools@v0.0.0-20190910165522-3cd124fa3ebb/internal/lsp/text_synchronization.go:32 +0x183 golang.org/x/tools/internal/lsp.(*Server).DidOpen(0xc000234240, 0x17e3180, 0xc000278240, 0xc000252040, 0xc000252040, 0x0) 	/Users/marius/go/pkg/mod/golang.org/x/tools@v0.0.0-20190910165522-3cd124fa3ebb/internal/lsp/server.go:134 +0x49 golang.org/x/tools/internal/lsp/protocol.serverHandler.Deliver(0x17f4d20, 0xc000234240, 0x17e3180, 0xc000278240, 0xc000278280, 0x0, 0xc000046730) 	/Users/marius/go/pkg/mod/golang.org/x/tools@v0.0.0-20190910165522-3cd124fa3ebb/internal/lsp/protocol/tsserver.go:113 +0x1cc7 golang.org/x/tools/internal/jsonrpc2.(*Conn).Run.func1(0xc0001ba5a0, 0xc000278280, 0xc0002342a0, 0x17e3180, 0xc000278240, 0x0, 0x0, 0xc000276d90) 	/Users/marius/go/pkg/mod/golang.org/x/tools@v0.0.0-20190910165522-3cd124fa3ebb/internal/jsonrpc2/jsonrpc2.go:370 +0x13a created by golang.org/x/tools/internal/jsonrpc2.(*Conn).Run 	/Users/marius/go/pkg/mod/golang.org/x/tools@v0.0.0-20190910165522-3cd124fa3ebb/internal/jsonrpc2/jsonrpc2.go:354 +0x8d8

This appears to be caused by this recent change. Gopls works fine with acme-lsp on the commit prior.

[gopherbot]

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

[ianthehat]

Looks like acme-lsp is sending a didopen call before initialized, which it is not allowed to do.
We would have survived that before, although there would have been subtle bugs.
There is still a bug we should fix here (crashes are never ok) but if I am right then the fix is to start obeying the spec and rejecting all messages before the initialize handshake is done, in which case acme-lsp is still going to be broken until that is fixed as well.

[mariusae]

Thanks, I'll take this over to the acme-lsp issue.

[fhs]

acme-lsp wasn't sending the initialized notification after the initialize request. The spec isn't exactly very clear. There is no mention of the notification in the initialize request sections:

Until the server has responded to the initialize request with an InitializeResult, the client must not send any additional requests or notifications to the server. In addition the server is not allowed to send any requests or notifications to the client until it has responded with an InitializeResult, with the exception ...