New issue
Advanced search Search tips

Issue 733730 link

Starred by 6 users
Status: Assigned
Owner:
keishi@chromium.org
Cc:
etienneb@chromium.org
tzik@chromium.org
tasak@google.com
yosin@chromium.org
keishi@chromium.org
haraken@chromium.org
primiano@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug

Blocked on:
issue 734427
issue 719880
Blocking:
issue 733323



Sign in to add a comment

Potential memory leak of DOM objects.

Project Member Reported by erikc...@chromium.org, Jun 15 2017 
I've been running Chrome with memory profiling enabled. I started with a gmail tab that I used for ~2 weeks. Then I forced a GC, navigated to about:blank, and then forced another GC. The renderer that was hosting the about:blank frame still has >10 thousand DOM objects that have not been destroyed. This seems likely to be a leak. These stats come from a renderer that is only hosting about:blank.

Raw & processed data: https://bugs.chromium.org/p/chromium/issues/detail?id=733323#c2
Methodology: https://docs.google.com/document/d/1fN5balfyrd7sRpd6DRaUI1TwoOwYjLyRSd7mwZT5US8/edit#

Each screenshot shows:
  1) # of objects created [that have not been destroyed]
  2) The stack trace of the code that created the object.
Screen Shot 2017-06-15 at 10.56.12 AM.png
97.3 KB View Download
Screen Shot 2017-06-15 at 10.56.18 AM.png
80.7 KB View Download
Screen Shot 2017-06-15 at 10.56.23 AM.png
77.6 KB View Download
Screen Shot 2017-06-15 at 10.56.35 AM.png
156 KB View Download

Comment 1 by erikc...@chromium.org, Jun 15 2017 

we're also leaking a comparable number of layout objects from malloc.
Screen Shot 2017-06-15 at 11.04.45 AM.png
158 KB View Download

Comment 2 by haraken@chromium.org, Jun 15 2017

Cc: tzik@chromium.org tasak@google.com

Comment 3 Deleted

Comment 4 by keishi@chromium.org, Jun 19 2017

Cc: yosin@chromium.org
The fact that the bloat persists after navigating to about:blank indicates a Blink memory leak bug.

If Blink leaks a single DOM node, it has a reference to Document so it will also leak the entire DOM tree, which means it will leak most CSS related objects and Resources. (because they're all GCed objects)
So looking at the diff doesn't help much.

But what tasak and I found interesting is the fact that LayoutObjects seem to be leaking. When we shutdown the Document we detach the layout tree so the fact that we have so many LayoutObjects leaking, we think, indicates that updateLayout is being called after Document is detached.

+yosin Do you know if we can/should add a CHECK for DoucmentLifecycle checking if layout is happening after Document::shutdown()? We already have DCHECKS.

Comment 5 by yosin@chromium.org, Jun 20 2017 

>#c4 Do you know if we can/should add a CHECK for DoucmentLifecycle checking if layout is happening after Document::shutdown()?

How about checking DocumentLifecycle::kStopping just before lifecycle_.AdvanceTo(DocumentLifecycle::kStopped) in Document::shutdown()?

In non-DCHECK, build DocumentLifecycle::AdvanceTo() doesn't call CanAdvanceTo(). This means we can update layout during kStopping.

Since AdvanceTo(kStopping) is only one place, Document::shutdown(), we can narrow down callers in
Document::shutdown() by move up CHECK(kStoppping) until AdvanceTo(kStopping).

Comment 6 by erikc...@chromium.org, Jun 20 2017

Owner: keishi@chromium.org
Status: Assigned (was: Untriaged)
keishi: Can you add the relevant CHECKs?

Comment 7 by tkent@chromium.org, Jun 23 2017

Blockedon: 734427 719880

Comment 8 by hayato@chromium.org, Aug 4 2017

Components: -Blink>DOM Blink>MemoryAllocator
►

Sign in to add a comment