You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My server is built with go1.7beta2 (go version devel +fca9fc5 Thu Jun 16 19:45:33 2016 +0000 linux/amd64).
I'm using go tool pprof from go1.7beta2 and a more recent version of tip:
go version devel +fca9fc5 Thu Jun 16 19:45:33 2016 +0000 darwin/amd64
go version devel +395f6eb Wed Jun 22 21:15:51 2016 +0000 darwin/amd64
What operating system and processor architecture are you using (go env)?
linux/amd64 server, darwin/amd64 for go tool pprof
What did you do?
I ran go tool pprof http://.../debug/pprof/profile from my darwin/amd64 machine to collect and view a CPU profile over the network of a process running on linux/amd64 (with the web and top subcommands).
What did you expect to see?
I expected the profile to include the names of the functions that were being executed, as collected by a follow-up call to the /debug/pprof/symbol endpoint.
What did you see instead?
The profile did not include function names, and all of the CPU cycles were attributed to a single node (named after the app).
I switched to "addresses" mode, and saw that CPU cycles were attributed to many different addresses (as I'd expect).
I suspect this is related to 4223294 and so only affects GOOS=linux profilees; that the presence of the mapping paths causes go tool pprof to attempt local symbolization and to not try the remote mode.
This doesn't appear to be #16128, as I'm able to reproduce it with a version of go tool pprof that includes 252eda4.
I included the -symbolize=remote flag in my invocation of go tool pprof, and the resulting profile included function names. The "heap" profile works as expected without adding that flag. Remote CPU profiles should work without that flag (as they do in go1.6.x and earlier).
The text was updated successfully, but these errors were encountered:
My server is built with go1.7beta2 (go version devel +fca9fc5 Thu Jun 16 19:45:33 2016 +0000 linux/amd64).
I'm using
go tool pprof
from go1.7beta2 and a more recent version of tip:go version devel +fca9fc5 Thu Jun 16 19:45:33 2016 +0000 darwin/amd64
go version devel +395f6eb Wed Jun 22 21:15:51 2016 +0000 darwin/amd64
linux/amd64 server, darwin/amd64 for
go tool pprof
I ran
go tool pprof http://.../debug/pprof/profile
from my darwin/amd64 machine to collect and view a CPU profile over the network of a process running on linux/amd64 (with theweb
andtop
subcommands).I expected the profile to include the names of the functions that were being executed, as collected by a follow-up call to the /debug/pprof/symbol endpoint.
The profile did not include function names, and all of the CPU cycles were attributed to a single node (named after the app).
I switched to "addresses" mode, and saw that CPU cycles were attributed to many different addresses (as I'd expect).
I suspect this is related to 4223294 and so only affects GOOS=linux profilees; that the presence of the mapping paths causes
go tool pprof
to attempt local symbolization and to not try the remote mode.This doesn't appear to be #16128, as I'm able to reproduce it with a version of
go tool pprof
that includes 252eda4.I included the
-symbolize=remote
flag in my invocation ofgo tool pprof
, and the resulting profile included function names. The "heap" profile works as expected without adding that flag. Remote CPU profiles should work without that flag (as they do in go1.6.x and earlier).The text was updated successfully, but these errors were encountered: