Remove filenames when showing function (default) granularity
Previously we were showing filenames together with function names
when generating reports at function granularity. This was an attempt
to provide more information to the user, but it clutters the output.
Also, in cases where a function is associated to multiple files
(eg template instantiations in C++), keeping the filename may prevent
us from combining nodes from the same function.
Will stop keeping filenames at the default function granularity, and will
remove the "functionnameonly" option which was previously providing this
functionality.
Do not honor call_tree option when generating non-visual reports.
There is a check to only honor the call_tree option when generating non-visual
reports, but it wasn't being checked in all appropriate places, causing a
mismatch that triggered a panic.
In changeset f90721db3d, fetch.go was changed to handle
the correct home directory environment variable on Plan 9
and Windows, but the tests were still using the $HOME
environment variable.
We change the tests to use the homeEnv function instead
of the $HOME environment variable.
Fixes #100.
Allow binary override for profiles with no mappings (#89)
The go runtime generates profiles in profile.proto format
without symbols or mappings. The expectation is that these
can be symbolized by passing the binary name to pprof.
The mechanism pprof uses relies to override the binary relies
on there being a mapping, and previously we moved the creation
of fake mappings to the legacy profile handlers, so profiles
parsed from profile.proto with no mappings can no longer be
symbolized.
Special case this situation to create a fake mapping and associate
all locations to it if there is a command line override but no
mappings.
For certain formats (eog, evince, gv, web, weblist), the visualizer
would be invoked regardless of whether the user specified a specific
output file to write to. In order to ensure that output is properly
written, the invokeVisualizer function has a check for whether the
output is os.Stdout and alters behavior based on that. This is the
wrong abstraction layer to do that work.
At the core of the problem is that PostProcess is used to both
do data post-processing that is inherent to the format, and also
to invoke some visualization for the data (to Stdout or browser).
We split these two steps apart and make it obvious which is which
by adding a visualizer field to Command.
This seperation of concerns allows us to simplify the code.
Upstreaming change from golang/go@39366326.
HTTP body will be read and displayed when both conditions are true:
* Response includes non-empty header "X-Go-Pprof".
* Content-Type is text/plain.
profile.parseGoCount: accept non-space characters in profile type.
In addition to the "goroutine" and "threadcreate" profiles,
Go code can generate custom profiles using the runtime/pprof package.
The user must name these profiles, and the docs recommend using the
convention "import/path" to avoid namespace conflicts. This CL
updates the pprof tool to be able to parse legacy profiles whose types
contain slashes and other non-space characters.
This is the upstream fix for https://github.com/golang/go/issues/13195.
This change will need to be mirrored to
github.com/golang/go/src/cmd/pprof/internal/profile/legacy_profile.go
Do not attempt to symbolize /dev/dri/* and [heap] files.
Trying to symbolize files like /dev/dri/renderD128 makes pprof hang as
it tries to read from this device file. So do not attempt the symbolization.
Skip [heap] file, too - the profile from issue #78 has a couple samples
in the heap (perhaps some generated code) and trying to locate a file
with that name can't succeed.
Fixes #78.
Alexey Alexandrov