Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/pprof: web/weblist visualization failure caused by incorrect web browser invocation is hard to debug #25853

Closed
marwan-at-work opened this issue Jun 12, 2018 · 9 comments

Comments

@marwan-at-work
Copy link
Contributor

@marwan-at-work marwan-at-work commented Jun 12, 2018

Please answer these questions before submitting your issue. Thanks!

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

1.10.3

Does this issue reproduce with the latest release?

yes

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

GOARCH="amd64"
GOOS="darwin"

What did you do?

Running a simple profiler with the following two lines of code:

pprof.StartCPUProfile(os.Stdout)
defer pprof.StopCPUProfile()

Create a file with output such as cpu.prof and run pprof cpu.prof

In the CLI, run web to open up a webpage
or run weblist <function-name>

What did you expect to see?

A web page with the profile svg or html correctly displayed.

What did you see instead?

FATAL[0000] couldn't read file: /Users/xxx/go/src/github.com/marwan-at-work/xxx/var/folders/n4/35bgdnkd6vlgqrdzbyl0x1ycmhcndx/T/pprof002.svg error=open /Users/xxx/go/src/github.com/marwan-at-work/xxx/var/folders/n4/35bgdnkd6vlgqrdzbyl0x1ycmhcndx/T/pprof002.svg: no such file or directory
pprof: exit status 1

Noting that the file (pprof002.svg) actually does exist under /var/folders/n4/35bgdnkd6vlgqrdzbyl0x1ycmhcndx/T/pprof002.svg but not /Users/xxx/go/src/github.com/marwan-at-work/xxx/var/folders/n4/35bgdnkd6vlgqrdzbyl0x1ycmhcndx/T/pprof002.svg

@marwan-at-work marwan-at-work changed the title cmd/pprof web command thinks the temp path is inside $GOPATH cmd/pprof web command thinks the temp path is inside $GOPATH or CWD Jun 12, 2018
@marwan-at-work marwan-at-work changed the title cmd/pprof web command thinks the temp path is inside $GOPATH or CWD cmd/pprof web command thinks the temp path is inside CWD Jun 12, 2018
@ysmolsky
Copy link
Member

@ysmolsky ysmolsky commented Jun 13, 2018

There must be something in your program which produces some side effect resulting in this. Maybe your program writes into stdout/stderr. Can you paste your program?

@marwan-at-work
Copy link
Contributor Author

@marwan-at-work marwan-at-work commented Jun 13, 2018

@ysmolsky it turns out I had a chrome binary that had nothing to do with Google Chrome and it was executing that one instead. But this makes me realize that the chrome command for MacOS is incorrect because AFAIK the Chrome command is this: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome.

The reason this has been working for most people on Mac, I assume, is because of the last command /usr/bin/open which opens the svg file directly when a user types web in the pprof cli. However this could open the svg file in an editor instead of a browser depending on what your default application for the .svg extension.

My suggestion is to add the real Chrome path mentioned above as one of the mac os commands to run. Probably in line 343 for reference: https://github.com/google/pprof/blob/master/internal/driver/commands.go#L340-L343

Happy to hear your thoughts and submit a pr unless you see something incorrect about my assumptions above. Thanks

@ysmolsky
Copy link
Member

@ysmolsky ysmolsky commented Jun 13, 2018

@marwan-at-work
I am sorry, but adding a specific path to the specific Chrome does not sound right. The right approach is to relay on system command which open file by associatio setup in user OS. The way it works right now. You might want to fix your OS so that /usr/bin/open chooses the right application for SVG file.

@marwan-at-work
Copy link
Contributor Author

@marwan-at-work marwan-at-work commented Jun 13, 2018

@ysmolsky I agree with the specific path to Chrome (although this is the default binary path for every macOS chrome browser).

Furthermore, I personally have never seen chrome or google-chrome as binaries in PATH on a MacOS before. I could be wrong of course. But having them might just be more confusing if someone actually has a chrome binary that's unrelated to the browser.

I wonder if there's a way to warn the user so they wouldn't spend 3-5 hours like I did being confused as to why "chrome" wasn't working with pprof. Maybe just default to /usr/bin/open?

Thanks!

@ysmolsky
Copy link
Member

@ysmolsky ysmolsky commented Jun 13, 2018

One thing that I have noticed is that pprof does not report an error when the first found vizualizer have returned an error:

% cat $(which chrome)
#!/bin/sh
echo ERROR
exit 1
% go tool pprof prof.prof
Main binary filename not available.
Type: cpu
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) web
(pprof)

That means that I cannot reproduce your problem. Also did you run go tool pprof or pprof?..

Wait a second. The pprof code you linked to above is not in Go project. You might want to address it there.

Ping @hyangah for some ideas.

@marwan-at-work
Copy link
Contributor Author

@marwan-at-work marwan-at-work commented Jun 14, 2018

@ysmolsky the error that i got was actually from the "random" chrome binary that I had so it's becoming irrelevant to the findings that followed :) Maybe I should update the issue title and description? Let me know, thanks!

@hyangah hyangah changed the title cmd/pprof web command thinks the temp path is inside CWD cmd/pprof: web/weblist visualization failure caused by incorrect web browser invocation is hard to debug Jun 14, 2018
@hyangah
Copy link
Contributor

@hyangah hyangah commented Jun 14, 2018

I filed a new issue in google/pprof. That's a better place for the discussion.
@marwan-at-work Did the failure from your chrome command cause the pprof CLI to exit as well?

@marwan-at-work
Copy link
Contributor Author

@marwan-at-work marwan-at-work commented Jun 14, 2018

@hyangah it did not.

@hyangah
Copy link
Contributor

@hyangah hyangah commented Jun 14, 2018

Good. Thanks for the update. I will close this bug for now.

@hyangah hyangah closed this Jun 14, 2018
@hyangah hyangah removed the WaitingForInfo label Jun 14, 2018
@golang golang locked and limited conversation to collaborators Jun 14, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.