x/tools/cmd/goimports: recent commit using 700% of CPU

[kevinburke1]

I try to stay close to the tip of x/tools (generally compiling every day or other day). Today I noticed goimports using 700% of my CPU after several hours of the fan being on (not unusual for the fan to go on on my machine, but unusual for it to go for several hours.) I'm running darwin and Go tip. It was not using that much RAM. It had been running for at least 7 hours according to Activity Monitor.

I'm not sure of the best way to troubleshoot that problem going forward, just wanted to make you aware of it in case you notice it on your machine or can think of a recent commit that could cause the CPU to spin.

[mdempsky]

Is the process still alive? If you can get a few backtraces from it, that might be interesting to help track down where/why it's using up so much CPU.

[kevinburke1]

No, it was running in the background in a Vim session. Can you describe how to get backtraces? I can try it if it happens again.

[mdempsky]

The intrusive way is to use kill -ABRT, which should cause it to immediately exit and print a backtrace. See the documentation at https://golang.org/pkg/runtime/ for "The GOTRACEBACK variable" for more ways to control this backtrace output using environment variables.

A somewhat better approach would be to attach a debugger to the process, grab a backtrace, let the process continue again for a couple seconds, grab another backtrace, etc., until you've got maybe 3 or more backtraces. That would give us a good idea where goimports is spending all its CPU time.

However, I don't actually have much experience using debuggers, and much less on macOS. Maybe someone else can suggest the best way to proceed there. I would think lldb should work though.

[kevinburke1]

I've used strace -f to attach to a running process before on Mac, though if it's not interacting with the filesystem that won't help much, could try that.

[dmitshur]

/cc @heschik per owners.