x/tools/gopls: specific sequence hangs if -logfile not passed

[myitcv]

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

$ go version
go version devel +135c9f45ec Wed Mar 31 04:13:44 2021 +0000 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.1.1-0.20210325171239-63ea654b4772
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.0.0-20210325171239-63ea654b4772

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
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/myitcv/.cache/go-build"
GOENV="/home/myitcv/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/myitcv/gostuff/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/myitcv/gos"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="devel +135c9f45ec Wed Mar 31 04:13:44 2021 +0000"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/gostuff/src/github.com/myitcv/govim/go.mod"
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3061377610=/tmp/go-build -gno-record-gcc-switches"

What did you do?

The following sequence, run with govim, succeeds if a -logfile flag is passed to gopls:

• Open govim
• Trigger workspace symbol search for cue.Value.Fill
• Open file that contains definition for cue.Value.Fill
• Exit

The logfile is as follows: good.log

However, that same sequence appears to hang gopls if the -logfile flag is not passed.

What did you expect to see?

gopls behaving the same (modulo logging) in both cases.

What did you see instead?

An apparently "stuck" gopls instance.

cc @stamblerre

FYI @leitzler

[stamblerre]

When gopls hangs, can you send kill -SIGABRT <pid> to get the stack trace and see where it's stuck?

[myitcv]

Rather embarrassingly (although perhaps not surprisingly) this is an error on the govim side. Without a -logfile flag, gopls logs to stderr. We relay gopls' stderr to the govim log file, using a bufio.Scanner. And that was the cause of the issue: the scanner was failing on a long line (notice the file in question above is relatively large)... but this error was not being reported in govim's log file. So this manifested as a gopls "hang" - but that was because the reading go routine on the govim side had crashed (ultimately debugged by comparing stack dumps of govim).

Apologies for the noise.