profile: change error message to print string representation of wire type (#514)
The proto write type code stored in buffer stores unprintable values
(e.g. 2 when unmarshalling). The desired output when printing an error
message is the string representation of the integer (i.e. strconv.Itoa),
instead of the current behavior string(int) or string(rune), which
return the utf8 literal corresponding to the integer.
As pointed out by @ianlancetaylor in
https://github.com/google/pprof/commit/4ac0da8#commitcomment-37524728, commit
4ac0da8 preserves the previous incorrect behavior to pass a vet check,
whereas this change prints the desired output.
Updates golang/go#32479.
As per the vet check being introduced in 1.15
(https://github.com/golang/go/issues/32479), conversions of the form
string(int) are flagged by go vet. The suggested fix is to instead use
string(rune).
Additionally, since google/pprof is vendored into the go tree, we avoid
test failures from vet flagging this dependency (see
CL https://go-review.googlesource.com/c/go/+/220977).
Make tag filter of the form `-tagfilter=foo=1` work. (#509)
Tag filters like `-tagfilter=foo=1` currently cannot be used to filter
by a unitless numeric tag as the tag filter regular expression expects
the unit part to be always present. They can be made working by using
`-tagfilter=foo=1unit` instead, but that's weird syntax. So fix this by
merely making the unit part optional.
I was wondering if this simple fix could have any unintended effects but
as far as I can tell from testing it does not.
* Add go.mod/go.sum
* travis: update to test in modules mode and with go1.13
Remove go1.11 setup
* fix appveyor config
AppVeyor sets the latest go stack in C:\go and that is GOROOT.
Cloning this repo under C:\go\src\.. directory confused go build
(as discussed in golang/go#34657). The fix in go is not yet
released. Thus this commit changes GOPATH to c:\gopath and clones
the repo under the directory.
Also, this commit removes the go get commands intended to pull in
dependencies. In modules mode, `go build` pulls in the required
dependencies.
webhtml: reenable sort option for flamegraphs (#491)
This sorts flamegraph elements lexographiaclly such that two similar
profiles can be compared side-by-side to eyeball differences in
flamegraph profile shapes and sizes.
Add back one GetBase heuristic, apparently kernel ASLR related. (#428)
After importing pprof with #425 included to the Google's code base
a test in the symbolizer started to fail. The name of the test appears
to be related to handling the perf data from systems with kernel ASLR
related and this case turns out to depend on one of the heuristics I've
removed in #425 (I assumed that had only be used for user-mode
binaries). Add that heuristic back and add a test case with the input
equivalent to the internally failing test.
I have to say I do not quite understand the test case here as I thought
we already have a kernel ASLR test case here, and there the mmap offset
field looks more like a kernel page offset value (i.e. in the upper half
of the address space), but here it's a small number. For now just want
to make sure the existing test cases work as they were.
Fix ELF base calculation for exec mapping with offset != 0. (#425)
I was looking at a report where pprof wouldn't symbolize the data
collected for a Chrome binary using Linux perf (b/112303003). The mmap
information is:
start: 0000000002, limit: 0000000006, offset: 0000000002
The ELF file header:
elf.FileHeader{Class:elf.ELFCLASS64, Data:elf.ELFDATA2LSB, Version:elf.EV_CURRENT, OSABI:elf.ELFOSABI_NONE, ABIVersion:0x0, ByteOrder:binary.LittleEndian, Type:elf.ET_EXEC, Machine:elf.EM_X86_64, Entry:0x272e000}
The code segment:
elf.ProgHeader{Type:elf.PT_LOAD, Flags:elf.PF_X+elf.PF_R, Off:0x252f000,
Vaddr:0x272e000, Paddr:0x272e000, Filesz:0x43da610, Memsz:0x43da610,
Align:0x1000}
The dynamic loader here mapped 0x6b09000-0x272e000 = 0x43db000 bytes
starting 0x252f000 file offset into 0x272e000 virtual address, exactly
as instructed by the program header (so, no ASLR). Thus, the base
adjustment should be zero. Yet, the current GetBase produced the base of
0x252f000 which is wrong. The reason for that is that the ET_EXEC branch
of GetBase doesn't handle the general case of non-zero mmap file offset,
but rather only supports a couple of special cases. This change makes
handling the case of user-mode ET_EXEC more generic.
Make '-noinlines' a separate flag, introduce '-filefunctions' granularity. (#420)
This change consists of two relatively independent parts, but they are
both about handling the granularity, so bundling them together.
First, in #415 there is a discussion that having a granularity mode by
source lines but with inlines hidden would be useful. The agreement is
also that adding `-linenoinlines` granularity would make the granularity
flags too messy (and they are already somewhat messy with `-addresses`
and `-addressnoinlines`. So, it was proposed to make `-noinlines` a
separate flag, which is what this change does. Note that the flag is now
pulled out of the granularity group so it's a bit of backward
incompatible change but I think it is acceptable. For the example in
issue #415 the user would now be able to specify `-list foo -noinlines`
to produce annotated source where the metrics from the inlined functions
are attributed to the calling inliner line.
With this change, I am also dropping the `-addressnoinlines` granularity
which is now supported as `-addresses -noinlines` combination. I
couldn't find any usage of this option at least internally at Google, so
I think it's safe to remove it.
Second, I am adding a separate `-filefunctions` granularity which groups
the data by both function and file. This is a follow-up to #110 from the
past where we changed the `-functions` granularity to not group by file
(it used to), and since then there was a couple of reports where using
just function name alone would over-aggregate the data in cases when a
function with the same name is contained in multiple source files (e.g.
see b/18874275 internally).
Also, make a number of assorted documentation and `-help` fixes.