x/tools/gopls: go list causes 100% CPU load

[kzhui125]

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

$ go version
go version go1.14 darwin/amd64

Does this issue reproduce with the latest release?

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

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN="/Users/zm/go/bin"
GOCACHE="/Users/zm/Library/Caches/go-build"
GOENV="/Users/zm/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/zm/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.14/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.14/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
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/_6/z1bzbqfn1h9byyv41hn2qgvc0000gn/T/go-build488495920=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I just use VSCode to edit go files.

What did you see instead?

I see the CPU fan is loud. then I see the "go" process use 100% CPU. After I quit VSCode, the "go" process still use 100% CPU. maybe the recent update of gopls is related?

Now I have force quit the "go" process, since the CPU fan is loud.

[gopherbot]

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.

[ALTree]

You didn't write so, but I'm guessing you're using the go lsp? And that go list invocation is from gopls? maybe @stamblerre can tell.

EDIT: oh sorry, you did write you updated gopls. I tagged this correctly then.

[stamblerre]

@kzhui125: Are you using modules or GOPATH mode? What was the root directory you opened gopls with? Can you run go list -e -json -compiled=true -test=true -export=false -deps=true --find=false -- fmt from the command line? Does it exit normally or does it print any errors?

[kzhui125]

I opened two VSCode windows (two small repos). One use go modules, another one only has one go file, didn't run "go mod init" yet.

When I run go list -e -json -compiled=true -test=true -export=false -deps=true --find=false -- fmt on the two repos, both exit normally and quicklly.

I will see if I meet this issue again in the future. Thanks.

[stamblerre]

@kzhui125: Have you encountered this issue again, or can this be closed?

[kzhui125]

Did not encounter this problem again, thanks.

[matthewmueller]

Unfortunately, I'm running into this now.

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

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%.

[stamblerre]

@matthewmueller: Do you mind opening a new issue, possibly with a gopls log if you're able to reproduce this? What gopls version were you using? What is the output of go env?

@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?

[matthewmueller]

Hey @stamblerre I just opened another issue: #42132