blob: 2e3d7b7a8db9cab20a24224951c7437e944bbb93 [file] [log] [blame]
// Copyright 2016 The Chromium Authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
syntax = "proto2";
option optimize_for = LITE_RUNTIME;
package metrics;
// Next tag: 10
message MemoryLeakReportProto {
// The call stack at which the leak was found. This is a list of offsets
// within the program binary. The first entry is the deepest level of the call
// stack.
// Some call stack entries may not be within the Chrome binary (e.g.
// JavaScript code). Those entries are given as the absolute offset in memory.
// The offsets within Chrome are determined by whether the original call stack
// address was within the executable region of the Chrome binary's mapping in
// memory. To symbolize these results, look up these values as offsets within
// the Chrome debug binary. If the value doesn't fit within the Chrome
// binary's offset range, then it is considered to be from another binary.
repeated uint64 call_stack = 1;
// Size of the memory allocation involved in the leak.
optional uint32 size_bytes = 2;
// Contains all parameters passed to the leak detector during initialization.
// Since these are known at the beginning, this message can be stored locally
// and then added to generated memory leak report protobufs.
// Next tag: 6
message Params {
// The rate at which allocations are pseudorandomly sampled. Ranges from 0
// to 1. A rate of 1 means all incoming allocations are sampled by the leak
// detector, which is the maximum possible.
optional float sampling_rate = 1;
// The max depth to which the call stacks were unwound by the leak detector.
// This may be greater than the size of |call_stack|.
optional uint32 max_stack_depth = 2;
// The leak analysis takes place every so often, with an interval based on
// the number of bytes allocated. This is independent of the sampling rate
// as it is computed from allocation sizes before sampling.
optional uint64 analysis_interval_bytes = 3;
// Suspicion thresholds used in leak analysis for size and call stacks,
// respectively. If an allocation size or call stack is suspected this many
// times in a row, the leak analysis escalates to the next level. For
// allocation sizes, the next level is to start analyzing by call stack. For
// call stacks, the next level is to generate a memory leak report.
optional uint32 size_suspicion_threshold = 4;
optional uint32 call_stack_suspicion_threshold = 5;
// Parameters used to initialize the leak detector.
optional Params params = 3;
// The type of Chrome process on which this leak report was generated.
enum ProcessType {
optional ProcessType source_process = 5;
// The build ID of the Chrome binary from which this leak report was obtained.
// The build ID is typically a 16- or 20-byte hash that is generated by the
// compiler that built the binary. This value will be read directly from the
// GNU build notes section of the Chrome binary.
optional bytes build_id = 6;
// Represents a single snapshot of the internal bookkeeping of the Runtime
// Memory Leak Detector, which tracks the number of extant allocations (a
// block of heap memory that has been allocated but not yet freed).
// Next tag: 3
message AllocationBreakdown {
// Table of number of extant allocations for each allocation size. The i-th
// entry in the vector is the net number of allocations for sizes in the
// range [i * 4, i * 4 + 3].
repeated uint32 counts_by_size = 1;
// The number of extant allocations with size = |size_bytes| and made from
// the call site given by |call_stack|. If it is not set, it means tracking
// of allocs per call site for allocation size = |size_bytes| has not yet
// begun at the time of this entry.
optional uint32 count_for_call_stack = 2;
// A record of past allocation data leading up to the circumstances that
// generated the current leak report.
// A new snapshot is taken every |analysis_interval_bytes| of memory
// allocation. The oldest record is at the beginning. The most recent record,
// taken at the time the report was generated, is at the end.
repeated AllocationBreakdown alloc_breakdown_history = 4;
// The following two fields describe the last increasing trend in the number
// of allocations from the size and call stack that generated this
// leak report.
// |num_rising_intervals| equals timeslot_now - timeslot_drop,
// where timeslot_drop is the timeslot number of the last frame that saw
// a drop in the number of allocations, or the first frame in the history
// if there were no drops (history is cleared when the net number of
// allocations hits 0).
// If it is < 32, it will be visible in the allocation history graph.
// If it is >= 32, it will not be seen in the graph.
// E.g. for history [3,2,4,4,7] |num_rising_intervals| equals 3.
optional uint32 num_rising_intervals = 7;
// Indicates the magnitude of the current uptrend in allocations.
// E.g. for history [3,2,4,4,7] |num_allocs_increase| equals 5.
optional uint32 num_allocs_increase = 8;
// Contains additional data about the memory usage from the OS.
// There is no need to store the total system memory as it is
// available under SystemProfileProto::Hardware::system_ram_mb.
// Next tag: 3
message MemoryUsageInfo {
// How much available physical memory the system has.
optional uint64 available_ram_mb = 1;
// Total private working set memory across all Chrome processes.
optional uint64 chrome_ram_usage_mb = 2;
// Information about the memory usage from the OS collected right after
// the leak report was created in the leak detector.
optional MemoryUsageInfo memory_usage_info = 9;