staticcheck and gopls nuke my computer

[bschaatsbergen]

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

bruno@pop-os ~> go version                                                                                                                                                                                                                                                  (base) 
go version go1.17.8 linux/amd64

Does this issue reproduce with the latest release?

Open a large code base in VS code.

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

go env Output

bruno@pop-os ~> go env                                                                                                                                                                                                                                                      (base) 
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/bruno/.cache/go-build"
GOENV="/home/bruno/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/bruno/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/bruno/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/linuxbrew/.linuxbrew/Cellar/go/1.17.8/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/linuxbrew/.linuxbrew/Cellar/go/1.17.8/libexec/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.8"
GCCGO="gccgo"
AR="ar"
CC="gcc-5"
CXX="g++-5"
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1077551622=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Open visual studio code, to be more specific aws-sdk-go project or the hashicorp/terraform-provider-aws project

What did you expect to see?

My project

What did you see instead?

I get logged out because my machine is having a hard time

[dominikh]

gopls doesn't invoke the Staticcheck binary. Even with Staticcheck enabled in gopls, the checks would execute directly in the gopls process. So this doesn't seem like a gopls issue.

[findleyr]

This may be a vscode-go issue, however.

CC @hyangah

[hyangah]

Agree that it's likely the vscode-go issue rather than gopls or go - @bschaatsbergen can you verify staticchecks are the children of a VSCode process?
One workaround is to disable staticcheck invocation by vscode-go, but delegate to gopls by enabling
"gopls": { "ui.diagnostics.staticcheck": true }

[ElanHasson]

I'm seeing similar here. downgrading to 0.8.0 seems to work with setting "go.toolsManagement.autoUpdate": false, in vscode settings

[findleyr]

Hi, fwiw I don't think gopls@v0.8.0 should make a difference relative to gopls@v0.8.1. @ElanHasson are you sure this matters?

[ElanHasson]

Several internal folks here have reported gopls as being slow for them and eating memory. As you mentioned this may be a vscode-go issue.

Downgrading seems to have resolved the issue for us. I did a quick search in vscode issues list and couldn't find anything relevant.

What is the best way to gather data on this to help diagnose the issue (or rule out gopls)?

[findleyr]

Gopls does use a lot of memory, but I'd be a bit surprised if it had a regression in v0.8.1, as that was mostly a bugfix release.

If you could run gopls@v0.8.0 on your codebase and report its RSS once it has finished loading, then compare with gopls@v0.8.1, that would be very helpful.

Which version of Go are you using, and do you use go workspace? go.work?

[ElanHasson]

❯ ps -o pid,vsz,rss,%mem,command -p $(ps -m -o pid=28227 | head -n1)
  PID    VSZ   RSS %MEM COMMAND
28227 3781784 1705460 10.5 /home/elan/go/bin/gopls -mode=stdio
❯ go version
go version go1.18 linux/amd64


❯ ps -o pid,vsz,rss,%mem,command -p $(ps -m -o pid=23130 | head -n1)
  PID    VSZ   RSS %MEM COMMAND
23130 14398852 12438852 76.5 /home/elan/go/bin/gopls -mode=stdio
❯ gopls version
golang.org/x/tools/gopls v0.8.1
    golang.org/x/tools/gopls@v0.8.1 h1:q5nDpRopYrnF4DN/1o8ZQ7Oar4Yd4I5OtGMx5RyV2/8=

  PID    VSZ   RSS %MEM COMMAND
13322 13516860 10040104 61.8 /home/elan/go/bin/gopls -mode=stdio
❯ gopls version
golang.org/x/tools/gopls v0.8.2
    golang.org/x/tools/gopls@v0.8.2 h1:+b7X2FDwmP7vxyYNOHe/ZFkecN5X8OtAgkNtuCr86wk=

I'd say this should be closed as the sluggishness has gone away.

[findleyr]

Thanks for following up!

[ElanHasson]

so, hate to be "that guy"...

Output from VSCode:

Starting linting the current package at /home/elan/repos/cthulhu/docode/src/do/teams/insights/executioner/pkg/execute
/home/elan/repos/cthulhu/docode/src/do/teams/insights/executioner/pkg/execute>Finished running tool: /home/elan/go/bin/staticcheck

Failed while handling 'onDidChangeTextDocument': TypeError: Cannot read properties of undefined (reading 'children')

[findleyr]

@ElanHasson your screenshot shows a lot of gopls processesthreads (using a ton of memory), but your output relates to staticcheck.

Can you clarify what you're pointing out? Do you know why you have so many gopls processesthreads?

EDIT: threads, not processes

[ElanHasson]

Hi @findleyr, I'm not sure-- I imagine it's a "feature" of VSCode.

I'm not sure if this is a VSCode problem (the staticcheck or multiple gopls). I figured I'd add details here for discoverability.

The previous RSS numbers I dropped were very low compared to these above. I'm unfamiliar with the internals of gopls or staticcheck nor how VSCode uses them.

I'm going to log an issue in https://github.com/microsoft/vscode and link to this for reference and operate under the impression it's a VSCode issue first.

I'd still say leave this closed unless the VSCode folks come back and say something otherwise.