-
Notifications
You must be signed in to change notification settings - Fork 17.3k
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/go: consider making "tool pprof" work with the module cache #48601
Comments
In module world, there can be multiple source roots where involved source files are. 1) module cache, 2) main module, and 3) local dependencies (replaced dependencies or picked by If Delve addresses a similar issue with users source mapping configuration that allows multiple mapping entries. https://github.com/go-delve/delve/tree/master/Documentation/cli#config
Can |
I do imagine this might require something more than the current
And the user could add extra maps, like |
We resisted adding the path substitution in pprof, this adds complexity that is rarely needed. There is google/pprof#611 in pprof (with google/pprof#612 that attempts to fix that), is this related? |
That kind of fix would certainly work :) I just didn't expect it would be acceptable for pprof to learn Go specifics. |
I was just debugging a server's large memory usage, so via its http pprof endpoints, I downloaded some profiles.
The binaries running on that server were built with
-trimprefix
, because it's a sane default for "production builds", and enables reproducible builds too.Unfortunately that means that, if I grab the deployed binary and some of its profiles, trying to use
go tool pprof
mostly works, but trying to inspect any source code fails:Adding
-source_path=$(go env GOMODCACHE)
fixes those cases:This won't cover quite all cases, because the main module lacks a version, and might not even be in the module cache if I built from a
git clone
. Note the lack of@module-version
in the error output, unlike my previous example involving a dependency:I still think it would be neat for
go tool pprof
to come with a built-in-source_path=$(go env GOMODCACHE)
default. As far as I can tell, it can't hurt. It won't be perfect with handling the main module either, but that's okay.One alternative I do have, which will support listing all function sources, is to rebuild the same program with the same build flags but without
-trimpath
. Arguably that's the better solution if I want to be able to inspect all the source. However, that takes extra steps, and sometimes it might be difficult to figure out how to build a slight variant of exactly the same program at exactly the same version. So the sane(r) default that I propose here would probably be enough to perform a lot oflist
commands.Yet another question is how I could tell
go tool pprof
that all thego.vocdoni.io/dvote
module sources are in the directory/home/mvdan/src/dvote
. I don't think-source_path
is powerful enough for this right now, as I don't seem to be able to supply two paths. This also seems worth investigating in terms of UX, but it does seem like a separate idea.cc @hyangah @aalexand @cherrymui
The text was updated successfully, but these errors were encountered: