An error occurred fetching the project authors.
- 08 Nov, 2019 3 commits
-
-
Hana (Hyang-Ah) Kim authored
Change-Id: Ie4754fefba6057b1cf558d0096fe0e83355f8eff Reviewed-on: https://go-review.googlesource.com/c/go/+/205098 TryBot-Result: Gobot Gobot <gobot@golang.org> Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> Reviewed-by:
Keith Randall <khr@golang.org>
-
Hana (Hyang-Ah) Kim authored
Change-Id: Id270a3477bf1a581755c4311eb12f990aa2260b5 Reviewed-on: https://go-review.googlesource.com/c/go/+/205097 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Hana (Hyang-Ah) Kim authored
The pprof profile proto message expects inlined functions of a PC to be encoded in one Location entry using multiple Line entries. https://github.com/google/pprof/blob/5e96527/proto/profile.proto#L177-L184 runtime/pprof has encoded the symbolization information by creating a Location for each PC found in the stack trace and including info from all the frames expanded from the PC using runtime.CallersFrames. This assumes inlined functions are represented as a single PC in the stack trace. (https://go-review.googlesource.com/41256) In the recent years, behavior around inlining and the traceback changed significantly (e.g. https://golang.org/cl/152537, https://golang.org/issue/29582, and many changes). Now the PCs in the stack trace represent user frames even including inline marks. As a result, the profile proto started to allocate a Location entry for each user frame, lose the inline information (so pprof presented incorrect results when inlined functions are involved), and confuse the pprof tool with those PCs made up for inline marks. This CL attempts to detect inlined call frames from the stack traces of CPU profiles, and organize the Location information as intended. Currently, runtime does not provide a reliable and convenient way to detect inlined call frames and expand user frames from a given externally recognizable PCs. So we use heuristics to recover the groups - inlined call frames have nil Func field - inlined call frames will have the same Entry point - but must be careful with recursive functions that have the same Entry point by definition, and non-Go functions that may lack most of the fields of Frame. The followup CL will address the issue with other profile types. Change-Id: I0c9667ab016a3e898d648f31c3f82d84c15398db Reviewed-on: https://go-review.googlesource.com/c/go/+/204636Reviewed-by:
Keith Randall <khr@golang.org>
-
- 08 Jan, 2019 1 commit
-
-
Keith Randall authored
In 1.11 we stored "return addresses" in the result of runtime.Callers. I changed that behavior in CL 152537 to store an address in the call instruction itself. This CL reverts that part of 152537. The change in 152537 was made because we now store pcs of inline marks in the result of runtime.Callers as well. This CL will now store the address of the inline mark + 1 in the results of runtime.Callers, so that the subsequent -1 done in CallersFrames will pick out the correct inline mark instruction. This CL means that the results of runtime.Callers can be passed to runtime.FuncForPC as they were before. There are a bunch of packages in the wild that take the results of runtime.Callers, subtract 1, and then call FuncForPC. This CL keeps that pattern working as it did in 1.11. The changes to runtime/pprof in this CL are exactly a revert of the changes to that package in 152537 (except the locForPC comment). Update #29582 Change-Id: I04d232000fb482f0f0ff6277f8d7b9c72e97eb48 Reviewed-on: https://go-review.googlesource.com/c/156657Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 28 Dec, 2018 1 commit
-
-
Keith Randall authored
Work involved in getting a stack trace is divided between runtime.Callers and runtime.CallersFrames. Before this CL, runtime.Callers returns a pc per runtime frame. runtime.CallersFrames is responsible for expanding a runtime frame into potentially multiple user frames. After this CL, runtime.Callers returns a pc per user frame. runtime.CallersFrames just maps those to user frame info. Entries in the result of runtime.Callers are now pcs of the calls (or of the inline marks), not of the instruction just after the call. Fixes #29007 Fixes #28640 Update #26320 Change-Id: I1c9567596ff73dc73271311005097a9188c3406f Reviewed-on: https://go-review.googlesource.com/c/152537 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Chase <drchase@google.com>
-
- 07 Sep, 2018 1 commit
-
-
Marko Kevac authored
If binary file of a running program was deleted or moved, maps file (/proc/pid/maps) will contain lines that have this binary filename suffixed with "(deleted)" string. This suffix stayed as a part of the filename and made remote profiling slightly more difficult by requiring from a user to rename binary file to include this suffix. This change cleans up the filename and removes this suffix and thus simplify debugging. Fixes #25740 Change-Id: Ib3c8c3b9ef536c2ac037fcc14e8037fa5c960036 Reviewed-on: https://go-review.googlesource.com/116395 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Hyang-Ah Hana Kim <hyangah@gmail.com>
-
- 16 Jul, 2018 1 commit
-
-
Hana (Hyang-Ah) Kim authored
Profile's Mapping field is currently populated by reading /proc/self/maps. On systems where /proc/self/maps is not available, the profile generated by Go's runtime will not have any Mapping entry. Pprof command then adds a fake entry and links all Location entries in the profile with the fake entry to be used during symbolization. https://github.com/google/pprof/blob/a8644067d5a3c9a6386e7c88fa4a3d9d37877ca3/internal/driver/fetch.go#L437 The fake entry is not enough to suppress the error or warning messages pprof command produces. We need to tell pprof that Location entries are symbolized already by Go runtime and pprof does not have to attempt to perform further symbolization. In #25743, we made Go runtime mark Mapping entries with HasFunctions=true when all Location entries from the Mapping entries are successfully symbolized. This change makes the Go runtime add a fake mapping entry, otherwise the pprof command tool would add, and set the HasFunctions=true following the same logic taken when the real mapping information is available. Updates #19790. Fixes #26255. Tested pprof doesn't report the error message any more for pure Go program. Change-Id: Ib12b62e15073f5d6c80967e44b3e8709277c11bd Reviewed-on: https://go-review.googlesource.com/123779 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
- 13 Jun, 2018 1 commit
-
-
Hana Kim authored
The pprof tool utilizes attributes of mapping entries such as HasFunctions to determine whether the profile includes necessary symbol information. If none of the attributes is set, pprof tool tries to read the corresponding binary to use for local symbolization. If the binary doesn't exist, it prints out error messages. Go runtime generated profiles without any of the attributes set so the pprof tool always printed out the error messages. The error messages became more obvious with the new terminal support that uses red color for error messages. Go runtime can symbolize all Go symbols and generate self-contained profile for pure Go program. Thus, there is no reason for the pprof tool to look for the copy of the binary. So, this CL sets one of the attributes (HasFunctions) true if all PCs in samples look fully symbolized. For non-pure Go program, however, it's possible that symbolization of non-Go PCs is incomplete. In this case, we need to leave the attributes all false so pprof can attempt to symbolize using the local copy of the binary if available. It's hard to determine whether a mapping includes non-Go code. Instead, this CL checks PCs from collected samples. If unsuccessful symbolization is observed, it skips setting the HasFunctions attribute. Fixes #25743 Change-Id: I5108be45bbc37ab486d145fa03e7ce37d88fad50 Reviewed-on: https://go-review.googlesource.com/118275 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
- 24 Apr, 2018 1 commit
-
-
Hana (Hyang-Ah) Kim authored
The Go's heap profile contains four kinds of samples (inuse_space, inuse_objects, alloc_space, and alloc_objects). The pprof tool by default chooses the inuse_space (the bytes of live, in-use objects). When analyzing the current memory usage the choice of inuse_space as the default may be useful, but in some cases, users are more interested in analyzing the total allocation statistics throughout the program execution. For example, when we analyze the memory profile from benchmark or program test run, we are more likely interested in the whole allocation history than the live heap snapshot at the end of the test or benchmark. The pprof tool provides flags to control which sample type to be used for analysis. However, it is one of the less-known features of pprof and we believe it's better to choose the right type of samples as the default when producing the profile. This CL introduces a new type of profile, "allocs", which is the same as the "heap" profile but marks the alloc_space as the default type unlike heap profiles that use inuse_space as the default type. 'go test -memprofile=...' command is changed to use the new "allocs" profile type instead of the traditional "heap" profile. Fixes #24443 Change-Id: I012dd4b6dcacd45644d7345509936b8380b6fbd9 Reviewed-on: https://go-review.googlesource.com/102696 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> Reviewed-by:
Russ Cox <rsc@golang.org>
-
- 24 Mar, 2018 1 commit
-
-
Daniel Martí authored
As found by unparam. Picked the low-hanging fruit, consisting only of errors that were always nil and results that were never used. Left out those that were useful for consistency with other func signatures. Change-Id: I06b52bbd3541f8a5d66659c909bd93cb3e172018 Reviewed-on: https://go-review.googlesource.com/102418 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
- 15 May, 2017 2 commits
-
-
Austin Clements authored
Currently proto symbolization uses runtime.FuncForPC and assumes each PC maps to a single frame. This isn't true in the presence of inlining (even with leaf-only inlining this can get incorrect results). Change PC symbolization to use runtime.CallersFrames to expand each PC to all of the frames at that PC. Change-Id: I8d20dff7495a5de495ae07f569122c225d433ced Reviewed-on: https://go-review.googlesource.com/41256 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Michael Matloob <matloob@golang.org>
-
Austin Clements authored
Proto profile conversion is inconsistent about call vs return PCs in profile locations. The proto defines locations to be call PCs. This is what we do when proto-izing CPU profiles, but we fail to convert the return PCs in memory and count profile stacks to call PCs when converting them to proto locations. Fix this in the heap and count profile conversion functions. TestConvertMemProfile also hard-codes this failure to convert from return PCs to call PCs, so fix up the addresses in the synthesized profile to be return PCs while checking that we get call PCs out of the conversion. Change-Id: If1fc028b86fceac6d71a2d9fa6c41ff442c89296 Reviewed-on: https://go-review.googlesource.com/42951 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Michael Matloob <matloob@golang.org>
-
- 28 Apr, 2017 1 commit
-
-
Michael Matloob authored
Profile labels added by the user using pprof.Do, if present will be in a *labelMap stored in the unsafe.Pointer 'tag' field of the profile map entry. This change extracts the labels from the tag field and writes them to the profile proto. Change-Id: Ic40fdc58b66e993ca91d5d5effe0e04ffbb5bc46 Reviewed-on: https://go-review.googlesource.com/39613 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
- 26 Apr, 2017 2 commits
-
-
Russ Cox authored
Change-Id: I72bea1450386100482b4681b20eb9a9af12c7522 Reviewed-on: https://go-review.googlesource.com/41816Reviewed-by:
Michael Matloob <matloob@golang.org>
-
Russ Cox authored
Delete old TestRuntimeFunctionTrimming, which is testing a dead API and is now handled in end-to-end tests. Change-Id: I64fc2991ed4a7690456356b5f6b546f36935bb67 Reviewed-on: https://go-review.googlesource.com/41815 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Michael Matloob <matloob@golang.org>
-
- 20 Apr, 2017 1 commit
-
-
Austin Clements authored
The period recorded in CPU profiles is in nanoseconds, but was being computed incorrectly as hz * 1000. As a result, many absolute times displayed by pprof were incorrect. Fix this by computing the period correctly. Change-Id: I6fadd6d8ad3e57f31e8cc7a25a24fcaec510d8d4 Reviewed-on: https://go-review.googlesource.com/40995 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Michael Hudson-Doyle <michael.hudson@canonical.com> Reviewed-by:
Russ Cox <rsc@golang.org>
-
- 08 Mar, 2017 1 commit
-
-
Russ Cox authored
This helps systems that maintain an external database mapping build ID to symbol information for the given binary, especially in the case where /proc/self/maps lists many different files (for example, many shared libraries). Avoid importing debug/elf to avoid dragging in that whole package (and its dependencies like debug/dwarf) into the build of every program that generates a profile. Fixes #19431. Change-Id: I6d4362a79fe23e4f1726dffb0661d20bb57f766f Reviewed-on: https://go-review.googlesource.com/37855 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
- 07 Mar, 2017 1 commit
-
-
Daniel Martí authored
It's only ever called with the value it was using, but the code was counterintuitive. Use the parameter instead, like the other funcs near it. Found by github.com/mvdan/unparam. Change-Id: I45855e11d749380b9b2a28e6dd1d5dedf119a19b Reviewed-on: https://go-review.googlesource.com/37893Reviewed-by:
Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 24 Feb, 2017 3 commits
-
-
Russ Cox authored
The existing code builds a full profile in memory. Then it translates that profile into a data structure (in memory). Then it marshals that data structure into a protocol buffer (in memory). Then it gzips that marshaled form into the underlying writer. So there are three copies of the full profile data in memory at the same time before we're done. This is obviously dumb. This CL implements a fully streaming conversion from the original in-memory profile to the underlying writer. There is now only one copy of the profile in memory. For the non-CPU profiles, this is optimal, since we have to have a full copy in memory to start with. For the CPU profiles, we could still try to bound the profile size stored in memory and stream fragments out during the actual profiling, as Go 1.7 did (with a simpler format), but so far that hasn't been necessary. Change-Id: Ic36141021857791bf0cd1fce84178fb5e744b989 Reviewed-on: https://go-review.googlesource.com/37164 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
Michael Matloob <matloob@golang.org>
-
Russ Cox authored
The old hash table was a place holder that allocates memory during every lookup for key generation, even for keys that hit in the the table. Change-Id: I4f601bbfd349f0be76d6259a8989c9c17ccfac21 Reviewed-on: https://go-review.googlesource.com/37163 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Michael Matloob <matloob@golang.org>
-
Russ Cox authored
This doesn't change the functionality of the current code, but it sets us up for exporting the profiling labels into the profile. The old code had a hash table of profile samples maintained during the signal handler, with evictions going into a log. The new code just logs every sample directly, leaving the hash-based deduplication to an ordinary goroutine. The new code also avoids storing the entire profile in two forms in memory, an unfortunate regression introduced when binary profile support was added. After this CL the entire profile is only stored once in memory. We'd still like to get back down to storing it zero times (streaming it to the underlying io.Writer). Change-Id: I0893a1788267c564aa1af17970d47377b2a43457 Reviewed-on: https://go-review.googlesource.com/36712 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Michael Matloob <matloob@golang.org>
-
- 10 Feb, 2017 1 commit
-
-
Russ Cox authored
These are very tightly coupled, and internal/protopprof is small. There's no point to having a separate package. Change-Id: I2c8aa49c9e18a7128657bf2b05323860151b5606 Reviewed-on: https://go-review.googlesource.com/36711 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
- 07 Feb, 2017 1 commit
-
-
Michael Matloob authored
When generating pprof profiles in proto format, symbolize the profiles. Change-Id: I2471ed7f919483e5828868306418a63e41aff5c5 Reviewed-on: https://go-review.googlesource.com/34192 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
- 10 Nov, 2016 1 commit
-
-
Michael Matloob authored
This change buffers the entire profile and converts in one shot in the profile writer, and could use more memory than necessary to output protocol buffer formatted profiles. It should be possible to convert each chunk in a stream (maybe maintaining some minimal state to output in the end) which could save on memory usage. Fixes #16093 Change-Id: I946c6a2b044ae644c72c8bb2d3bd82c415b1a847 Reviewed-on: https://go-review.googlesource.com/33071 Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
- 08 Nov, 2016 1 commit
-
-
Michael Matloob authored
This change adds code, originally written by Russ Cox <rsc@golang.org> and open-sourced by Google, that converts from the "legacy" binary pprof profile format to a struct representation of the new protocol buffer pprof profile format. This code reads the entire binary format for conversion to the protobuf format. In a future change, we will update the code to incrementally read and convert segments of the binary format, so that the entire profile does not need to be stored in memory. This change also contains contributions by Daria Kolistratova <daria.kolistratova@intel.com> from the rolled-back change golang.org/cl/30556 adapting the code to be used by the package runtime/pprof. This code also appeared in the change golang.org/cl/32257, which was based on Daria Kolistratova's change, but was also rolled back. Updates #16093 Change-Id: I5c768b1134bc15408d80a3ccc7ed867db9a1c63d Reviewed-on: https://go-review.googlesource.com/32811 Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
- 31 Oct, 2016 1 commit
-
-
Michael Matloob authored
This reverts commit b33030a7. Reason for revert: We're going to try to get the code in this change submitted in smaller, more carefully reviewed changes. Change-Id: I4175f4b297f0e69fb78b11f9dc0bd82f27865be7 Reviewed-on: https://go-review.googlesource.com/32441Reviewed-by:
Russ Cox <rsc@golang.org>
-
- 28 Oct, 2016 3 commits
-
-
Michael Matloob authored
Original Change by Daria Kolistratova <daria.kolistratova@intel.com> Added functions with suffix proto and stuff from pprof tool to translate to protobuf. Done as the profile proto is more extensible than the legacy pprof format and is pprof's preferred profile format. Large part was taken from https://github.com/google/pprof tool. Tested by hand and compared the result with translated by pprof tool, profiles are identical. Fixes #16093 Change-Id: I2751345b09a66ee2b6aa64be76cba4cd1c326aa6 Reviewed-on: https://go-review.googlesource.com/32257 Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Alan Donovan <adonovan@google.com>
-
Austin Clements authored
This reverts commit 7d14401b. Reason for revert: Doesn't build. Change-Id: I766179ab9225109d9232f783326e4d3843254980 Reviewed-on: https://go-review.googlesource.com/32256Reviewed-by:
Russ Cox <rsc@golang.org>
-
unknown authored
Added functions with suffix proto and stuff from pprof tool to translate to protobuf. Done as the profile proto is more extensible than the legacy pprof format and is pprof's preferred profile format. Large part was taken from https://github.com/google/pprof tool. Tested by hand and compared the result with translated by pprof tool, profiles are identical. Fixes #16093 Change-Id: I5acdb2809cab0d16ed4694fdaa7b8ddfd68df11e Reviewed-on: https://go-review.googlesource.com/30556 Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Michael Matloob <matloob@golang.org>
-