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.
Improve regexp matching of mappings for legacy formats
Simplify regexps and define a recommended format:
Start End object file name offset(optional) linker build id
0x40000-0x80000 /path/to/binary (@FF00) abc123456
Also include some additional tests and move existing tests to legacy_profile_test.go,
closer to the code in legacy_profile.go.
Populate more carefully the profile.proto in the topproto output
Instead of putting a pretty-printed string on the function.name,
populate the function.name, .file and location line with the
information from the node. This will help more easily extract this
information.
Also add some cachign to reuse functions and added a small test.
Previous loc information on assembly listing was being printed for
every line, while the intent was to print it only when it changes.
Also update the tests to expose and test that case, and remaster
other tests to match.
Disassembly reports generated by pprof -disasm will now include line number
information as generated by objdump. This will make the generated assembly more
readable.
As part of this I've introduced a new assemblyInstruction struct. Previously
the code was reusing the graph.Node to represent assembly instructions but it
seems better to have a dedicated type for this.
Do not hide allocation frames under call32/call64.
See https://github.com/google/pprof/issues/54. Frames under
call32/call64 may be user code frames so should be shown to avoid
confusing re-attribution of allocations to the calling system frames.
Raul Silvera