Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
cmd/pprof: spurious "Main binary filename not available." error #26255
I just created a heap profile using go test -memprofile=x.prof. When I run pprof on it, the first line of output is:
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:
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):
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.
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.
Can you upload the profile, or add how to produce the profile?
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?
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."