High CPU when go to definition in wrong code

[ulrichSchreiner]

hi,

i regularly use F12 or STRG+CLICK to jump to a reference. i do not know since when, but when i do this in "wrong" code all of my 4 cpu's jump to high usage, and the top 3 performers is "code"

top:
 307 usc       20   0 1810928 298160  87920 R  82,7   1,8   4:11.53 code
 208 usc       20   0  388268 134616 104256 R  28,7   0,8   1:48.15 code
 177 usc       20   0 1241328 135020  91496 S  17,7   0,8   1:00.63 code

and i'm doing nothing in vscode. only wait for it. my go-code looks like this:

        ....
	c, err := mc.GetConfiguration()
	if err != nil {
		return nil, fmt.Errorf("cannot fetch configuration: %v", err)
	}
-->	c.GetString(key string, def string)
	return iws, nil

the marked line was inserted with "STRG+SPACE" and this is completly correct. but it does not compile, as it is not correct code. now i wanted to jump to the definition of "GetString" to see the exact definition of the parameters and this does not work (ok i can live with this as the code does not compile). but now my CPU's go wild and never goes down again until i restart vscode.

and no, there is no guru or any other background process which eats lot of cpu/memory. only the code process.

as described, i can wait 10 minutes or an hour ... the cpu never comes down again.

Version: 1.28.2
Commit: 7f3ce96ff4729c91352ae6def877e59c561f4850
Datum: 2018-10-17T00:20:56.183Z
Electron: 2.0.9
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
Architektur: x64

vscode-go: 0.6.93

[ulrichSchreiner]

one more note: when i change the code so that it compiles, everything works. and this also "repairs" code. so when change the upper code to

	_, err := mc.GetConfiguration()
	if err != nil {
		return nil, fmt.Errorf("cannot fetch configuration: %v", err)
	}
	//c.GetString(key string, def string)
	return nil, nil

and jump to the definition of GetConfiguration this works and the CPU of code comes down again.

[ramya-rao-a]

@ulrichSchreiner Thanks for reporting.

• Can you share your Go related settings?
• Can you share a small sample code where you see this issue, so that I can give it a try?
• What version of Go are you using?
• What OS are you on?
• Next time this happens, run Developer: Open Process Explorer. Under extensionHost, you should be able to see any long running process started by the extension

[ulrichSchreiner]

hi,

go1.11.2 on linux:

$ go version
go version go1.11.2 linux/amd64

when creating a simple programm

package main

import (
	"fmt"
	"io/ioutil"
	"os"
)

func main() {
	fmt.Println("hallo")
	ioutil.ReadAll(os.Stdin)
	//ioutil.ReadAll(r io.Reader)
}

doing a CTRL-CLICK on the first ReadAll vscode jumps to the definition of this function. when commenting in the last line and do a CTRL-CLICK on the second ReadAll (which is illegal code) the cpu increases with 3-4 code processes. on my current pc every process uses about 15-20% cpu. on my notebook with my original code (in a really big workspace) the CPU jumps up to 80%.

after commenting out the last line again and do a CTRL-CLICK on the first ReadAll everything is fine again.

the "Developer -> Process Explorer" does not show any high CPU usage. but the linux top shows 3-4 code processes with significat cpu usage.

{
    "go.lintTool": "revive",
    "go.useLanguageServer": false,
    "go.languageServerFlags": ["-trace", "-logfile","/tmp/lang.log"],
    "go.inferGopath": true,
    "go.liveErrors": {
        "enabled": true,
        "delay": 500
    },
    "go.buildOnSave": "package",
    "go.coverageOptions": "showCoveredCodeOnly",
    "go.coverageDecorator": {
        "type": "highlight"
    },
    "go.languageServerExperimentalFeatures": {
        "format": false,
        "autoComplete": false,
    },
    "go.enableCodeLens": {
        "references": false,
        "runtest": true
    },
    "go.autocompleteUnimportedPackages": true,
    "go.coverOnSingleTest": true,
    "go.docsTool": "gogetdoc",
    "go.useCodeSnippetsOnFunctionSuggest": true,
    "go.useCodeSnippetsOnFunctionSuggestWithoutType": false,
    "go.vetOnSave": "off",
    "go.gotoSymbol.includeGoroot": true,
    "go.gotoSymbol.includeImports": true,
}

[ulrichSchreiner]

it only happens when there is a bug in the code. here

package main

import (
	"fmt"
	"io/ioutil"
	"os"
)

func main() {
	fmt.Println("hallo")
	ioutil.ReadAll(os.Stdin)
}

everything is fine. but here:

package main

import (
	"fmt"
	"io/ioutil"
	"os"
)

func main() {
	fmt.Pri ntln("hallo")
	ioutil.ReadAll(os.Stdin)
}

the "Go to definition" (F12) on the ReadAll does not work and CPU increases.

[MelleKoning]

I've got the same sympthon; very high CPU usage that does not come back down.

In task manager it is visible that guru.exe is being called and eats up the CPU% and memory.
Same can be seen in developer processes:

So, 75% CPU usage and keeps on going.

The action was Find-All-References (Shift-Alt-F12) or Peek-References (Shift-F12)

Is there any reason guru.exe does not come back with results or is it continuously restarted by the vscode-go module?

-edit- Might this be related to a very large vendor folder, that it simply takes a very long time for guru to process all the *.go files in the project? If yes, might Find-all-references be limited to certain packages as per the command line of guru.exe option "scope packages"? See guru command line params below.

Flags:
  -cpuprofile file
        write CPU profile to file
  -json
        emit output in JSON format
  -modified
        read archive of modified files from standard input
  -ptalog file
        write points-to analysis log to file
  -reflect
        analyze reflection soundly (slow)
  -scope packages
        comma-separated list of packages the analysis should be limited to
  -tags build tags
        a list of build tags to consider satisfied during the build. For more information about build tags, see the description of build constraints in the documentation for the go/build package

[ramya-rao-a]

@ulrichSchreiner Apologies for the very late response, but I am able to see the same issue as you when I change go.docsTool to gogetdoc.
If you change go.docsTool to godoc, you won't see the perf problem any more.

This was caused by gogetdoc getting stuck and not returning.
The fix here should be two-fold

• gogetdoc should fix it at their end. I have logged gogetdoc gets stuck when operating on files with errors zmb3/gogetdoc#56 for this
• The Go extension should apply a timeout and not wait for the process to keep running. Logged Add timeouts for every process (except the ones that run in server mode) spawned by the extension  #2348 for this

@MelleKoning Since this issue originally was about the Go to definition feature, I have moved your concern to a new issue. See #2347