Unable to reproduce the issue on Win-7 and Win-10 using chrome reported version #65.0.3325.181 and latest canary #67.0.3394.0.

Following are the steps followed to reproduce the issue.
------------
1. Executed attached test html file.(texture_memory_leak.html)
2. Wait for about 4 hours.
3. Did not observe any tab crash.

toshi24730@ - Could you please provide crash id from chrome://crashes for further triaging from TE end. 

Thanks...!!

Thanks for your support.
My environment is Windows 10 64 bit.
Have you tried it with 64 bit?

Crash report sent.
ID: 3a0da1c7-7fce-4c76-9569-ec883eee5077

I tried this crash report with the attached new html. And the result was the same.

Deleted: memory_leak2.html 4.4 KB

memory_leak2.html 4.4 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

That's SkTDynamicHash.h.

Testers, try this on a low memory device, please, but not Android One. Maybe a low memory chromebook?

Looks like that hash can/will never shrink, which is generally a bad thing for long running workloads.

Tried testing the issue on a available low memory (8GB) surface pro device using chrome reported version #65.0.3325.181 and latest canary #67.0.3394.0.

Observed that after waiting for about 4 hours, the tab did not crash.
Hence, forwarding the issue to inhouse team for further triaging of the issue.

Thanks...!!

It seems that the behavior changes depending on GPU rasterization setting.

The GPU of Chrome crashing PC (Win-10 64 bit) is as follows.

  Intel HD Graphics 530
  Intel HD Graphics 2500

Chrome's GPU rasterization was enabled by default in these environments.
(See attached image)

I tested again with GPU rasterization disabled from chrome: // flags. Huge memory allocation did not occur.
Therefore, I think this problem will occur when GPU rasterization is enabled.

Please try to test in an environment GPU rasterization is enabled.

Deleted: chrome_gpu.PNG 22.2 KB

	chrome_gpu.PNG 22.2 KB View Download

From comment #1, this appears to be an issue with runaway allocations from SkTDynamicHash. This makes me think that something being used in the above SVG (maybe path rendering or text?) has a cache which has no upper limit (at least for the hash keys).

Will run this with heap profiler and see if I see anything obvious.

The most obvious SVG-side cache here is probably the one for patterns. It'll be per-object though and not unbounded. I guess it would be possible that the patterns cause a lot of raster-side objects to be created.

Tracing GrResourceCache, I see stuff like this after about 45min:


** SkTDynamicHash[0x1156cac59710] add - count: 16335, capacity: 524288, alloc: 92274688 bytes
*** changeUniqueKey - res: 0x1156cbc04b38, key: 0xea871b18, count[0x1156cac59710]: 16336
 ...
 ...
 ...
** SkTDynamicHash[0x1156cac59710] add - count: 16335, capacity: 1048576, alloc: 184549376 bytes
*** changeUniqueKey - res: 0x1156cf25e6b8, key: 0x424242a2, count[0x1156cac59710]: 16336


So the number of entries is bounded (16336), but the capacity/allocation size does creep up.

What I think is going on:

1) we are cycling through a bazillion picture shaders on repaint -- unnecessarily, but that's a different issue: either Blink is not caching the pattern data (unlikely) or CC is building new shaders on the fly for color-space conversion (likely, I recall other perf bugs around this)

2) IIUC, SkTDynamicHash behaves poorly with volatile entries: removed entries are marked deleted and not made available for reuse, and the strategy is to always growing exponentially

So I think fs@ is onto something (as usual): SkTDynamicHash's storage can grown indefinitely when churning.  Relevant logic:

        if (100 * (fCount + fDeleted + 1) > fCapacity * kGrowPercent) {
            this->resize(fCapacity > 0 ? fCapacity * 2 : 4);
        }

I think it would make sense to just "re-compact" when (fDeleted / fCount) is high, instead of always growing -- which should be as simple as calling this->resize(fCapacity).

The following revision refers to this bug:
  https://skia.googlesource.com/skia/+/c274f8f942bf756fc78ab01992aecb855231f9e3

commit c274f8f942bf756fc78ab01992aecb855231f9e3
Author: Florin Malita <fmalita@chromium.org>
Date: Wed Apr 18 21:46:33 2018

Prevent unnecessary/unbounded growth of SkTDynamicHash capacity

SkTDynamicHash doesn't immediately recycle slots for removed entries,
but instead just marks them as deleted.

The only way to reclaim deleted slots currently is when an exponential
grow/resize is triggered.

A consequence of this is that the capacity/allocated storage can grow
indefinitely when the hash is long-lived and churning -- even if the
number of active entries is small/stable.

To prevent this, I propose we only grow the capacity when the number of
active slots constitutes a significant portion.  Otherwise (when most
slots are deleted), we trigger a "purge" (resize to the same capacity)
to clear the tombstones.

Bug:  chromium:832482 
Change-Id: Iefdcd7439f7d62ac021e176b71007d207c8bc876
Reviewed-on: https://skia-review.googlesource.com/122082
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Florin Malita <fmalita@chromium.org>

[modify] https://crrev.com/c274f8f942bf756fc78ab01992aecb855231f9e3/tests/DynamicHashTest.cpp
[modify] https://crrev.com/c274f8f942bf756fc78ab01992aecb855231f9e3/src/core/SkTDynamicHash.h

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

commit fbf12bb49278f24340aaf765c3595d996dfdf5b8
Author: skia-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com <skia-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Date: Thu Apr 19 13:40:00 2018

Roll src/third_party/skia/ 4c32956b1..2ae45ae83 (9 commits)

https://skia.googlesource.com/skia.git/+log/4c32956b1fee..2ae45ae83a57

$ git log 4c32956b1..2ae45ae83 --date=short --no-merges --format='%ad %ae %s'
2018-04-19 scroggo Revert "Add stub gpu workaround generators"
2018-04-19 caryclark path is rect track corners
2018-04-17 borenet Reland "[infra] Run recipes through Kitchen"
2018-04-19 angle-skia-autoroll Roll third_party/externals/angle2/ aaa19de06..eeec3b14c (1 commit)
2018-04-18 angle-skia-autoroll Roll third_party/externals/angle2/ 5804dc8ea..aaa19de06 (9 commits)
2018-04-18 enne Add stub gpu workaround generators
2018-04-18 herb Move strike cache Find*() to strike cache
2018-04-18 liyuqian Remove SK_SUPPORT_LEGACY_PATH_DAA_BIT
2018-04-18 fmalita Prevent unnecessary/unbounded growth of SkTDynamicHash capacity

Created with:
  roll-dep src/third_party/skia
BUG= chromium:829614 , chromium:824145 , chromium:829614 , chromium:832482 


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

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=master.tryserver.blink:linux_trusty_blink_rel;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
TBR=scroggo@chromium.org

Change-Id: I6d92732f2ff872d7b5c1df456c66cc54a4615abc
Reviewed-on: https://chromium-review.googlesource.com/1019381
Commit-Queue: skia-chromium-autoroll <skia-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Reviewed-by: skia-chromium-autoroll <skia-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#551999}
[modify] https://crrev.com/fbf12bb49278f24340aaf765c3595d996dfdf5b8/DEPS

I'm not 100% sure it's the only thing going on with this SVG, but after c274f8f942bf756fc78ab01992aecb855231f9e3 the huge SkTDynamicHash allocations should be gone (locally stable at ~11MB).

Closing tentatively. 

@toshi24730 if you want to verify, wait a couple of days for the change to roll then test against a canary build.


(as a side note, the GPU rendering perf for the test is horrendous, and prolly warrants a separate bug/investigation)

Opened issue 834869 to investigate perf.

I tested it for about 50 hours with Canary # 68.0.3401.0.
As a result, the tab kept running without crashing.
Also, huge memory allocation did not occur.

However, it seems that memory is slightly increasing, I think that this is another cause.
(See attached image)

Deleted: perf_mon.png 28.8 KB

	perf_mon.png 28.8 KB View Download

The NextAction date has arrived: 2018-04-23