An error occurred fetching the project authors.
  1. 08 Nov, 2019 3 commits
  2. 08 Jan, 2019 1 commit
    • Keith Randall's avatar
      runtime: store incremented PC in result of runtime.Callers · 232c9793
      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: default avatarIan Lance Taylor <iant@golang.org>
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      232c9793
  3. 28 Dec, 2018 1 commit
    • Keith Randall's avatar
      cmd/compile,runtime: redo mid-stack inlining tracebacks · 69c2c564
      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: default avatarDavid Chase <drchase@google.com>
      69c2c564
  4. 07 Sep, 2018 1 commit
    • Marko Kevac's avatar
      runtime/pprof: remove "deleted" suffix while parsing maps file · 73b8e5f8
      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: default avatarHyang-Ah Hana Kim <hyangah@gmail.com>
      73b8e5f8
  5. 16 Jul, 2018 1 commit
    • Hana (Hyang-Ah) Kim's avatar
      runtime/pprof: add a fake mapping when /proc/self/maps is unavailable · ba022644
      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: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      ba022644
  6. 13 Jun, 2018 1 commit
    • Hana Kim's avatar
      runtime/pprof: set HasFunctions of mapping entries · 7b2f55d8
      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: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      7b2f55d8
  7. 24 Apr, 2018 1 commit
    • Hana (Hyang-Ah) Kim's avatar
      runtime/pprof: introduce "allocs" profile · cd037bce
      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: default avatarRuss Cox <rsc@golang.org>
      cd037bce
  8. 24 Mar, 2018 1 commit
  9. 15 May, 2017 2 commits
    • Austin Clements's avatar
      runtime/pprof: expand inlined frames in symbolized proto profiles · 9e83c11f
      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: default avatarMichael Matloob <matloob@golang.org>
      9e83c11f
    • Austin Clements's avatar
      runtime/pprof: clean up call/return PCs in memory profiles · 1dc0f969
      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: default avatarMichael Matloob <matloob@golang.org>
      1dc0f969
  10. 28 Apr, 2017 1 commit
  11. 26 Apr, 2017 2 commits
  12. 20 Apr, 2017 1 commit
  13. 08 Mar, 2017 1 commit
    • Russ Cox's avatar
      runtime/pprof: add GNU build IDs to Mappings recorded from /proc/self/maps · c797256a
      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: default avatarIan Lance Taylor <iant@golang.org>
      c797256a
  14. 07 Mar, 2017 1 commit
  15. 24 Feb, 2017 3 commits
    • Russ Cox's avatar
      runtime/pprof: add streaming protobuf encoder · cbab65fd
      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: default avatarMichael Matloob <matloob@golang.org>
      cbab65fd
    • Russ Cox's avatar
      runtime/pprof: use more efficient hash table for staging profile · 1564817d
      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: default avatarMichael Matloob <matloob@golang.org>
      1564817d
    • Russ Cox's avatar
      runtime/pprof: use new profile buffers for CPU profiling · 1a680a90
      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: default avatarMichael Matloob <matloob@golang.org>
      1a680a90
  16. 10 Feb, 2017 1 commit
  17. 07 Feb, 2017 1 commit
  18. 10 Nov, 2016 1 commit
    • Michael Matloob's avatar
      runtime/pprof: output CPU profiles in pprof protobuf format · 76f12cda
      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: default avatarRuss Cox <rsc@golang.org>
      76f12cda
  19. 08 Nov, 2016 1 commit
    • Michael Matloob's avatar
      runtime/pprof/internal: add package protopprof · f72a629d
      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: default avatarRuss Cox <rsc@golang.org>
      f72a629d
  20. 31 Oct, 2016 1 commit
  21. 28 Oct, 2016 3 commits