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: disasm not working #50891
Comments
but if the binary (which is in wd) is explicitly passed as FWIW, I see the same behaviour with go1.17.5 (above tests are from tip). (This is on Linux). |
Agreed, as far as I can tell this has never worked. This works (on linux-amd64):
Removing the release-blocker label. |
I stub my toe on this UX about every other time I use pprof. |
It seems the go command first runs the binary in the tmp directory, collects the profile, then moves it to the current directory. The file path recorded is the one in the tmp directory.
Perhaps the go command can move the file first then run it? Another part is that it seems the file names recorded in the profile are from profile.Mapping, which is from reading /proc/self/maps, which probably works only on Linux. So on macOS we may need to always pass the executable file name to pprof, even if the go command does the mv first. |
Thanks. Indeed, not a release blocker. It should be easy to run the final executable instead of the one from /tmp to fix Linux. For the Mac we should be able to record os.Executable, which might be sufficient. All good things for a future release. |
Getting the same problem on Windows:
$ go version go version go1.17.6 windows/amd64
|
On my Mac, if I run go test -cpuprofile=x.prof anything, and then go tool pprof x.prof, then the disasm command in pprof does not work, for any function at all:
I have not checked whether this is Mac-specific.
The text was updated successfully, but these errors were encountered: