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: spurious "Main binary filename not available." error #26255

Closed
rsc opened this issue Jul 6, 2018 · 6 comments
Closed

cmd/pprof: spurious "Main binary filename not available." error #26255

rsc opened this issue Jul 6, 2018 · 6 comments

Comments

@rsc
Copy link
Contributor

@rsc rsc commented Jul 6, 2018

I just created a heap profile using go test -memprofile=x.prof. When I run pprof on it, the first line of output is:

Main binary filename not available.

I'm not 100% sure what this means, but it should not be printed. We just went through all the effort of making profiles stand alone so that the program binary is unnecessary for pprof's operation. The first thing it prints should not be a complaint about a file it does not need.

This print was introduced in Go 1.10:

$ go1.9 tool pprof x.prof
Type: alloc_space
Time: Jul 6, 2018 at 4:00pm (EDT)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) 

$ go1.10 tool pprof x.prof
Main binary filename not available.
Type: alloc_space
Time: Jul 6, 2018 at 4:00pm (EDT)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) 

Normally, a print introduced in Go 1.10 would not be a release blocker in Go 1.11. But now in Go 1.11 the print is in RED (or surrounded by line noise; see #26254):

$ go tool pprof x.prof
�[0;31mMain binary filename not available.
�[0mType: alloc_space
Type: alloc_space
Time: Jul 6, 2018 at 4:00pm (EDT)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) 

It's as though pprof REALLY wants us to know that it doesn't have a file it doesn't need. We made a big deal of not needing the main binary anymore. I don't want to confuse users with a spurious RED message.

@rsc rsc added this to the Go1.11 milestone Jul 6, 2018
@rsc rsc added the release-blocker label Jul 6, 2018
@rsc
Copy link
Contributor Author

@rsc rsc commented Jul 6, 2018

@hyangah Are you still taking care of pprof?

@hyangah
Copy link
Contributor

@hyangah hyangah commented Jul 6, 2018

The only place I could find with git grep is https://go.googlesource.com/go/+/master/src/cmd/vendor/github.com/google/pprof/internal/symbolizer/symbolizer.go#321

Strange. The fix for #25743 sets the HasFunctions field and is supposed to prevent printing of the error message.
I tried to reproduce it by generating a memory profile with go test on the fmt pkg, and couldn't reproduce it.

Can you upload the profile, or add how to produce the profile?

--
Oh, did you generate the profile with old Go (<=1.10)?

@hyangah
Copy link
Contributor

@hyangah hyangah commented Jul 6, 2018

I reproduced it on mac. There is no non-zero mapping at all.

@aalexand - I think it is too harsh to classify the lack of the file name as an error. What do you think?

@aalexand
Copy link
Contributor

@aalexand aalexand commented Jul 10, 2018

Can the runtime put in the non-zero mapping corresponding to the binary, on Mac? I believe there isn't /proc filesystem on OSX which makes it difficult, is that why it's missing? Having it would be useful when profiling non-pure Go programs (to symbolize locations that couldn't be symbolized by the runtime).

What apparently happens now is that this code executes adding a fake mapping since the profile itself does not have any mappings and later the symbolizer complains about that. Maybe, similar to what was done in #25743, we could set HasFunctions in this fake mapping if all locations it points to already have the function information. We could also just silently ignore mappings with empty file name (as in https://go.googlesource.com/go/+/master/src/cmd/vendor/github.com/google/pprof/internal/symbolizer/symbolizer.go#329 where the code skips mappings with name like "[vdso]") but I am less sure about that. If some locations were not symbolized, user may specify the binary path on the pprof command line and that will be used as the mapping name. Without any diagnostics the user wouldn't know that they can do this.

@rauls5382 FYI, thoughts on this?

@rauls5382
Copy link
Contributor

@rauls5382 rauls5382 commented Jul 10, 2018

I think the ideal fix would be to extend #25743 to have the Go runtime generate in OSX and other non-linux OSs an empty mapping and set HasFunctions on it. This would be appropriate for Go as it does online symbolization, but other profile sources do not. This would tell pprof that local symbolization isn't needed and it will bypass all of these checks.

Having said that, I agree this message isn't very useful as is, and we could just remove it. That would trigger the more useful (but also more verbose): "Some binary filenames not available. Symbolization may be incomplete. Try setting PPROF_BINARY_PATH to the search path for local binaries."

@gopherbot
Copy link

@gopherbot gopherbot commented Jul 13, 2018

Change https://golang.org/cl/123779 mentions this issue: runtime/pprof: add a fake mapping when /proc/self/maps is unavailable

@gopherbot gopherbot closed this in ba02264 Jul 16, 2018
@golang golang locked and limited conversation to collaborators Jul 16, 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
5 participants
You can’t perform that action at this time.