chromium/src
0
Fork 0
Code Activity

Update documentation for browsing heap dumps.

Browse Source 
Change-Id: Iacba2281ea810a3b4c56c36b4a0edcc66b456f40
Reviewed-on: https://chromium-review.googlesource.com/976088
Commit-Queue: Erik Chen <erikchen@chromium.org>
Reviewed-by: Timothy Dresser <tdresser@chromium.org>
Cr-Commit-Position: refs/heads/master@{#545151}
This commit is contained in:
erikchen
2018-03-22 18:04:19 +00:00
committed by Commit Bot
parent 8ce77a0228
commit fd7bb6c841
2 changed files with 7 additions and 6 deletions

3
docs/memory-infra/heap_profiler.md

@ -62,7 +62,8 @@ similar effect to the various `memlog` flags.
3. Scroll down all the way to _Heap Details_.
4. Pinpoint the memory bug and live happily ever after.
4. To navigate allocations, select a frame in the right-side pane and press
Enter/Return. To pop up the stack, press Backspace/Delete.
[memory-infra]: README.md
[m-purple]: https://storage.googleapis.com/chromium-docs.appspot.com/d7bdf4d16204c293688be2e5a0bcb2bf463dbbc3

10
docs/memory/debugging_memory_issues.md

@ -71,11 +71,11 @@ insight. At the time of this writing, heap dumps from the wild have resulted in
real, high impact bugs being found in Chrome code ~90% of the time.
* The first thing to do upon receiving a heap dump is to open it in the [trace
viewer](/docs/memory-infra/README.md). This will tell us the counts, sizes, and
allocating stack traces of the potentially leaked objects. Look for stacks
that result in >100 MB of live memory. Frequently, sets of objects will be
leaked with similar counts. This can provide insight into the nature of the
leak.
viewer](/docs/memory-infra/heap_profiler.md#how-to-manually-browse-a-heap-dump).
This will tell us the counts, sizes, and allocating stack traces of the
potentially leaked objects. Look for stacks that result in >100 MB of live
memory. Frequently, sets of objects will be leaked with similar counts. This
can provide insight into the nature of the leak.
* Important note: Heap profiling in the field uses
[poison process sampling](https://bugs.chromium.org/p/chromium/issues/detail?id=810748)
with a rate parameter of 10000. This means that for large/frequent allocations