The following revision refers to this bug:
  https://chromium.googlesource.com/catapult/+/a1878a94799dfc0a15fa7676315e3ac58920c382

commit a1878a94799dfc0a15fa7676315e3ac58920c382
Author: Erik Chen <erikchen@chromium.org>
Date: Mon Nov 12 20:47:40 2018

Update computation of load bias to handle CrOS edge cases.

We've now seen examples on CrOS where an ELF has several segments, and some of
the segments do not report the proper name in the memory map heap dump. This CL
updates the load bias computation to assume that all maps with the same name are
from the same ELF, and uses the start_address of the first such map to compute
the load bias of subsequent maps.

Bug: chromium:904492
Change-Id: I33344afdec7107a8c8f69e94cff4aec000154519
Reviewed-on: https://chromium-review.googlesource.com/c/1331887
Reviewed-by: Etienne Bergeron <etienneb@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>

[modify] https://crrev.com/a1878a94799dfc0a15fa7676315e3ac58920c382/tracing/tracing/extras/symbolizer/symbolize_trace.py

This leak is in a GMail tab on a system on which the Hangouts extension has been uninstalled, so I'm getting Hangouts moles popping up in that tab pretty often. The increase in RAM (which happens pretty quickly) seems correlated with my having uninstalled that.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/db30207d089b3b15fe717ceb7e1665dab1a84749

commit db30207d089b3b15fe717ceb7e1665dab1a84749
Author: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Date: Tue Nov 13 03:27:33 2018

Roll src/third_party/catapult 0cf6ee7f1acb..84f62b6f08e8 (2 commits)

https://chromium.googlesource.com/catapult.git/+log/0cf6ee7f1acb..84f62b6f08e8


git log 0cf6ee7f1acb..84f62b6f08e8 --date=short --no-merges --format='%ad %ae %s'
2018-11-12 cbruni@chromium.org [wprgo] Implement httparchive.go add and addAll command
2018-11-12 erikchen@chromium.org Update computation of load bias to handle CrOS edge cases.


Created with:
  gclient setdep -r src/third_party/catapult@84f62b6f08e8

The AutoRoll server is located here: https://autoroll.skia.org/r/catapult-autoroll

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.

CQ_INCLUDE_TRYBOTS=luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel

BUG=chromium:904492
TBR=sullivan@chromium.org

Change-Id: Ic4a8c9f0258bf1183c0f78bb2d996dd2ad94e423
Reviewed-on: https://chromium-review.googlesource.com/c/1333049
Reviewed-by: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#607471}
[modify] https://crrev.com/db30207d089b3b15fe717ceb7e1665dab1a84749/DEPS

- When I open blink_objects column I only see 716 Resource objects but cc::DecodeImageCache is leaking 7034 images.
- If you open the ImageDecoderWrapper::Decode stack from DecodingImageGenerator::GetPixels, I see GIFImageDecoder being used

Because of these two points I suspect these leaked images come from GIF frames.
I don't know enough about cc or image decoding so could an expert have a look?

Assigning to cblume@ who last touched GIFImageDecoder.