extension startup false & typing lag for "[warning] UNRESPONSIVE extension host, 'ms-vscode.Go'"

[zenchan]

go version
go1.13.5 windows/amd64
vscode version
Version: 1.44.1 (system setup)
Commit: a9f8623ec050e5f0b44cc8ce8204a1455884749f
Date: 2020-04-11T01:48:12.622Z
Electron: 7.1.11
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 6.1.7601
extension version
vscode-go 0.13.1
go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Administrator\AppData\Local\go-build
set GOENV=C:\Users\Administrator\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=D:\goworkspace
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\ADMINI~1\AppData\Local\Temp\go-build353559690=/tmp/go-build -gno-record-gcc-switches
go extension setting
"go.goroot": "C:\Go",
"go.gopath": "D:\goworkspace",
"go.vetFlags": ["-all", "-shadowstrict"],
"go.formatTool": "goimports",
"go.gotoSymbol.includeGoroot": true,
"go.gotoSymbol.includeImports": true,
"go.useCodeSnippetsOnFunctionSuggest": true,
"go.useLanguageServer": true,
"[go]": {
"editor.formatOnSave": true,
"editor.codeActionsOnSave": {
"source.organizeImports": true,
},
"editor.snippetSuggestions": "none",
},
"gopls": {
"usePlaceholders": true,
"staticcheck": false,
}

Describe the bug

extension startup false, and it lags when typing

Steps to reproduce the behavior:

1. Startup vscode
2. typing on go file, it lags

Screenshots or recordings

exthost-cpuprofile.zip

[hyangah]

Thanks for the report and the profile. @zenchan

From both profiles show go-outline (invoked to find benchmark functions for codelens) as the expensive operation. @ramya-rao-a can you please take a look?

About "startup":false in the log: I think that just indicates the go extension is not set up to get activated when start up, which is true - it is activated whenever a go file gets opened.

[zenchan]

@ramya-rao-a @hyangah Is there any plan to fix this? I had to disabled the extension for the typing lag. Thanks

[mbamber]

I am also getting this error now:

[2020-04-17 12:08:06.617] [renderer1] [warning] UNRESPONSIVE extension host, 'ms-vscode.Go' took 96% of 6030.041ms, saved PROFILE here: '/var/folders/nn/jd1fn7q92gq23tvd84t56j180000gp/T/exthost-ed279d.cpuprofile' [{"id":"eamodio.gitlens","total":358,"percentage":0},{"id":"gc","total":18935,"percentage":0},{"id":"ms-vscode.Go","total":5813139,"percentage":96},{"id":"ms-vsliveshare.vsliveshare","total":1283,"percentage":0},{"id":"program","total":38915,"percentage":1},{"id":"self","total":152596,"percentage":3},{"id":"vscode.git","total":4538,"percentage":0}]

This appears to spawn a significant number of processes, which causes chrome tabs to fail to load, VSCode to freeze and new terminal sessions to fail with:

[forkpty: Resource temporarily unavailable]
[Could not create a new process and open a pseudo-tty.]

At first I thought this might be to do with 0.14.1, but I can repro with 0.14.0 so maybe not

[hyangah]

@zenchan Does the program go away if codelens is disabled? ("[go]": { "editor.codeLens": false} That's not ideal but a temporary walkaround until the problem is fixed.

And if possible, try to run go-outline -f <one of your open go test file> to see if it works.

@mbamber are you using gopls? (gopls makes most of separate tools for different types of analysis unnecessary.) Is the problem reproducible with 0.13.x in your case? (I don't remember any changes that introduce additional process forking, but there were some changes in process cleanup)

Can you find the list of processes the extension spawned? (If ps doesn't give the info, alternative is to open the Developer: Open Process Explorer and watch while reloading the window).

[mbamber]

@hyangah I am not using gopls, and I cannot repro the problem with 0.13.1

I can confirm that loading a go file with 0.14.x causes a large number of pgrep processes to be spawned by the extension host:

[hyangah]

Thanks @mbamber - that's helpful. In the above go-outline command, btw, did you see the use of the -modified flag?

@quoctruong @ramya-rao-a @zmb3 can you please take a look? I believe tree-kill uses pgrep internally.

[mbamber]

Sorry @hyangah - which command are we talking about, I think I might be missing something

[hyangah]

@mbamber the go-outline command (partially redacted).

[mbamber]

Oh 🤦‍♂️ I see now. Yes the --modified flag is present.

[zmb3]

Wondering if this could be related to 16cbd97.

I would continue to use cp.kill() when we know the process we want to kill doesn't spawn any child processes. Using tree-kill to kill a single process is a bit much, as it has to launch at least one process in order to figure out what to kill. By the time this happens the original go-outline process probably already completed..

[zenchan]

@zenchan Does the program go away if codelens is disabled? ("[go]": { "editor.codeLens": false} That's not ideal but a temporary walkaround until the problem is fixed.

And if possible, try to run go-outline -f <one of your open go test file> to see if it works.

@mbamber are you using gopls? (gopls makes most of separate tools for different types of analysis unnecessary.) Is the problem reproducible with 0.13.x in your case? (I don't remember any changes that introduce additional process forking, but there were some changes in process cleanup)

Can you find the list of processes the extension spawned? (If ps doesn't give the info, alternative is to open the Developer: Open Process Explorer and watch while reloading the window).

@hyangah go-outline -f <my file> is worked.
("[go]": { "editor.codeLens": false} ) This really helpful for me, it's not lag when typing.
And i found out that when i disabled the setting "go.useLanguageServer": false, go-outline run with the flag -modified

[ramya-rao-a]

I would continue to use cp.kill() when we know the process we want to kill doesn't spawn any child processes.

The catch though is to know which processes spawns child processes and which don't.

[ramya-rao-a]

@zenchan, @mbamber, I have reverted the change 16cbd97 for just the go-outline tool in the latest beta version of the extension. Can you try this version, remove the "editor.codeLens": false setting that you added and let us know if the issue still persists?

[hyangah]

@butuzov, @abhishekkrm Can you try the new latest beta version with your original setting
("editor.codeLens": false, linter, ...) and report if the beta version fixed the issue?

[butuzov]

I can't confirm that beta fixed the issue. It's still there.

1. Installed beta.
2. Restored linter settings (at a minimum level to run only golint with in golangci-lint)
3. saved file with an error.
4. enjoyed an increased number of pgrep spawning in my system.

I am back to 0.13.0 wich looks not affected by this issue. feel free to ping me to test any new beta.

[ramya-rao-a]

@hyangah I only reverted the change to use tree-kill for the go-outline process as being discussed in this issue. @butuzov seem to be coming from #3191 which is about the linter and am not sure which issue is @abhishekkrm coming from.

Does golangci-lint fall under the category of tools that spawn sub processes?

[butuzov]

Does golangci-lint fall under the category of tools that spawn sub processes?

correct.

[hyangah]

@ramya-rao-a I think maybe we should revert the use of tree-kill not only for go-outline, but for most commands. I suspect those pgreps @mbamber saw are not from go-outline but from other tools invoked when not using gopls. @ahishekkrm reported #3189 which was resolved by reverting to 0.13.

[hyangah]

I have difficulty in reproducing the problem. If you have detailed instruction (settings.json, os, open files) and public repositories we can use to reproduce the bug, please share with us.

@butuzov what is the version of golangci-lint you are using? Do you have any custom configuration in use for the golangci-lint?

[butuzov]

https://www.youtube.com/watch?v=nR8gWDuSKVw

I am using golangci-lint of one of the previous versions, as binary in releases of the golangci-lint is build with go 1.14 (it has a serious issues on the platform I am using, so it prevents me of using any tools build with 1.14.0).

ping @hyangah

[stamblerre]

Let's continue the discussion on this in the upstream issue: golang/vscode-go#90.