go: x/tools/gopls: "stuck" at 100% CPU

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

$ go version
go version devel +1804bbab62 Tue Sep 24 18:20:52 2019 +0000 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.0.0-20190926165942-a8d5d34286bd
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.1.8-0.20190926165942-a8d5d34286bd

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"
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"
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-build780296000=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Enabled staticcheck within gopls
Opening a medium sized project (specifically this file https://github.com/cuelang/cue/blob/master/cmd/cue/cmd/export.go) I then randomly see indefinite 100% CPU 1 time in ~5 when opening a file in Vim via govim

There is clearly extra CPU required with staticcheck enabled, and I see that on startup. It’s just that 1 time in 5 something gets stuck

A kill -SIGABRT stack trace and gopls log file can be found here:

https://gist.github.com/myitcv/4ef84fd1115d27f1305566647278f72e

Disabling staticcheck within gopls I no longer see any problems.

What did you expect to see?

Normal operation

What did you see instead?

Per above

cc @stamblerre @ianthehat @dominikh

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 3
Comments: 24 (16 by maintainers)

Most upvoted comments

I’ve just done a test against 0cba7a3a with partial revert of CL 214586 applied on top, in the form of CL 215239, and things are massively improved. i.e. we don’t appear to suffer anywhere near the level of analysis “floods” we did before. Therefore I’m going to close this issue; we can always re-open if there are specific cases that do cause problems.

Thanks for all the fixes as ever @stamblerre 😄

myitcv on Jan 20, 2020

Thanks for the report, @ermik. If you are able to file an issue with a repro case and a log I can help you investigate the issues that you’ve noticed (see https://github.com/golang/tools/blob/master/gopls/doc/troubleshooting.md#capturing-logs for information on how to capture the logs).

stamblerre on Nov 9, 2019

I believe I am hitting this case as well. I find that it’s specifically triggered when refactoring code - VSCode submitting “incomplete” code to gopls really sends it off the deep end. This makes gopls really rough to work with at the moment.

This has been my experience on multiple versions, including the most recent at the moment 774d2ec1, though as of that version, even though it goes off the deep end, it’s not necessarily getting stuck “forever” anymore.

bmhatfield on Oct 22, 2019