x/tools/gopls: set a deadline on `go list` call in the initial workspace load

[matthewmueller]

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

$ go version
go version go1.15 darwin/amd64

$ gopls version
golang.org/x/tools/gopls v0.5.1
    golang.org/x/tools/gopls@v0.5.1 h1:AF3Uh7HF08SZpKFfgJO6zfF3bbxyDXWqdkK4kMXiQ1o=

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

go env Output

$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/m/Library/Caches/go-build"
GOENV="/Users/m/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/m/Go/pkg/mod"
GONOPROXY=""
GONOSUMDB="github.com/matthewmueller"
GOOS="darwin"
GOPATH="/Users/m/Go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
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/4f/tcxcr6_55v9bp38d8g4hjlf80000gn/T/go-build388962724=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

100% CPU utilization on go list.

Here's the command that's running:

m                11926 100.0  0.0  5084696     24   ??  R    10:58PM 790:42.08 go list -modfile=/var/folders/4f/tcxcr6_55v9bp38d8g4hjlf80000gn/T/go.81d65b897d3d2041650a7b316bfe7936e665c0667228e1aea9664629dbcc4506.974007766.mod -e -json -compiled=true -test=true -export=false -deps=true -find=false -modfile=/var/folders/4f/tcxcr6_55v9bp38d8g4hjlf80000gn/T/go.81d65b897d3d2041650a7b316bfe7936e665c0667228e1aea9664629dbcc4506.974007766.mod -- github.com/matthewmueller/mat.tm/duo/cli

It seems like go list is stuck trying to list a package that no longer exists.

Roughly the steps I took:

1. I had a directory called command: github.com/matthewmueller/mat.tm/duo/command
2. Renamed the directory from command to cli: github.com/matthewmueller/mat.tm/duo/cli
3. Changes all the package names from command to cli
4. Realized that was a dumb idea, changed all the packages back to command
5. Renamed the directory from cli back to command.
6. Noticed about an hour later that my CPU usage was at 100%.

---

Unfortunately, I don't have the gopls logs as far as I know. I closed VSCode in an effort to bring down CPU usage.

[heschi]

stamblerre:

@heschik: I believe you had previously looked into these issues (and resolved them with the gocommand package). Do you think it's possible that go list could hang for an hour for a nonexistent package?

This is clearly a go command bug, perhaps caused by the filesystem changing during a list run. I think you're asking if it could hang hitting the network, but I don't think so, and even if it did it would not use 100% cpu to do it.

The fact that gopls hasn't killed it suggests that whatever triggered the load was running detached, e.g. the IWL. Perhaps we should set a deadline of last resort like 5 minutes?

[stamblerre]

A deadline seems like a good idea--maybe we could add it as an experimental setting.

[matthewmueller]

Throwing this out there naively: could go list be used programmatically to avoid dealing with process lifecycles and cleanup?

[stamblerre]

Unfortunately not--gopls needs to use the version of go that the user is currently using, not the version with which gopls was compiled.