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.
Often profile handlers return no data, and pprof currently
returns "profile format unrecognized", which confuses users
and sends them on a wild goose chase.
Print a more explicit "empty input file" error message.
A previous commit attempted to handler mappings produces using the glog
package by matching the column on which the sentinel was found.
However, some tools generate the mapping using a single log entry,
where the prefix appears only on the first line.
Instead of matching by column, use a regexp to identify and match
prefixes introduced by the glog package.
If the memory map is generated by logging routines such as glog, they
may include some initial text which confuses the parsing of legacy
mappings. The initial text is the same for all mapping entries,
so detect it on the proc map sentinel and remove it from the mapping
entries.
Add a message recommending the use of PPROF_BINARY_PATH
The common mechanism to locate the main binary has several drawbacks:
- The identification of the main mapping is done through heuristics
- It can only override the main binary
PPROF_BINARY_PATH is a more robust mechanism, but it isn't widely known.
Add a message when symbolization fails recommending its usage.
Parse correctly mappings where the binary has been deleted
Entry mappings of the form:
" 02e00000-02e8a000: /foo/bin (deleted)"
are currently resulting in "(deleted)" being set as the build id.
Enforce the build id to be hex, and allow unrecognized junk to
be at the end of the mapping.
Combine adjacent mappings even if offsets are unavailable
Some profile handlers will split mappings into multiple adjacent
entries. This interferes with pprof when overriding the main binary.
Currently there is code that attempts to combine these mappings, but
it fails if the mapping offsets aren't available. Add a check to
combine them in that situation.
Hiroshi Ioka