1. What version of Go are you using (go version)?

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

1. What operating system and processor architecture are you using (go env)?

linux/amd64 server, darwin/amd64 for go tool pprof

1. 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).

1. 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.

1. 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).