-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
Comments
@hyangah Are you still taking care of pprof? |
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? -- |
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? |
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." |
Change https://golang.org/cl/123779 mentions this issue: |
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 text was updated successfully, but these errors were encountered: