x/tools/cmd/guru: implements can take extreme amount of resources (e.g. when run from vscode) depending on working directory #41243
Labels
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Tools
This label describes issues relating to any tools in the x/tools repository.
Milestone
Uh oh!
There was an error while loading. Please reload this page.
Hello, first of all, thanks for the work that's been put into guru. It's certainly been quite helpful to me over the years.
I know
guru
is no longer actively maintained (and I don't expect a resolution), but considering gopls is still in alpha, i thought it might be helpful to others (or to my future self) to document this issue.What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?go env
OutputI found out that based on the working directory when
guru implements
is run, it can take an extreme amount of cpu and take a very long time.In particular, consider these 3 types of runs:
only 1) returns in a reasonable amount of time. 2) is how visual studio code invokes it (when CWD is
$GOPATH/src/github.com/prometheus/prometheus
), and 3) is my attempt to fix the problem with 2) by constraining the scope.More info about each run:
Note:
I moved
guru
toguru-real
and replacedguru
with this script:this allows me to track the exact environment of the process each time it is run (particularly when the parent is vscode and not my terminal), but it turns out the issue was reproducible perfectly from a terminal, so at this point it's no longer useful, but it does explain why i have mentions of "guru-real" in the
pstree
output below.run 1
run 2
I didn't let it complete. I killed it after it ran for hours.
run 3
The text was updated successfully, but these errors were encountered: