New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 412414 link

Starred by 6 users

Issue metadata

Status: Fixed
Owner:
Closed: Jan 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 1
Type: Bug



Sign in to add a comment

Missing tiles due to OOM

Reported by vangelis@chromium.org, Sep 9 2014

Issue description

Version: 37
OS: OSX Retina Mac

What steps will reproduce the problem?
1. Open https://dl.dropboxusercontent.com/spa/jbj423z5m7y8em0/Exports/site_vitrineV4-2/site_vitrineV4-2.html

What is the expected output? What do you see instead?
Page is completely white. Turning on composited layer bounds shows a lot of layers and plenty of tiles with red outlines (OOM).  Surprisingly even the layers with non-red borders show no content. In the task manager the GPU memory usage for the tab is 484MB (definitely over the limit).


Please use labels and text to provide additional information.
In Chrome 37 the issue goes away with --disable-layer-squashing and --enable-impl-side-painting
In Chrome 39 the page works fine even with --disable-impl-side-painting.  It seems to be using quite a bit less memory.



 
Cc: ligim...@chromium.org
Labels: Needs-Bisect
Ligi, could you please bisect to figure out when in the 36 -> 37 span this issue started happening?

Rest of the folks cc-ed, could any of the recent compositor bugs that were fixed explain this behavior? 

This is probably also related to issue 408849 . 


Or, hm, I don't see any render surfaces. Maybe not.
> In Chrome 37 the issue goes away with --disable-layer-squashing and --enable-impl-side-painting

Does it go away with only one of those?
Labels: -Needs-Bisect OS-Windows
Able to reproduce this in Windows 7. Issue is reproducible in current Stable & Beta  but not in Canary.

36.0.1985.143 (Official Build 287914) - Not Reproducible
37.0.2062.103 (Official Build 291558) - Reproducible
38.0.2125.44 (Official Build 291484)  - Reproducible
39.0.2151.0 (Official Build 5ca466f14cd4b221b5e1340641fd6793621881bd-refs/heads/master@{#293895}) canary - Not Reproducible

Did a manual bisect , here is the Info.

Good Build :38.0.2095.0 (Official Build 283390)
Bad Build : 38.0.2096.0 (Official Build 283571) 

Regression Info
===============
Chromium CL - https://chromium.googlesource.com/chromium/src/+log/89a7a78de73f177430b37fc57ed9824fa50538d7..d99b556dc520dd18ce34135ed7506c461753c962

Blink CL - 
http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog_blink.html?url=/trunk&range=178286%3A178283

Unfortunately I am not seeing any offending CL here.

Update for comment #4
=====================

The issue goes away only with --disable-layer-squashing , disabling --enable-impl-side-painting has no effect.



This seems to be a layer squashing issue? Or is memory still excessively high without layer squashing?
Disabling impl-side painting is in there, so it sounds like this goes away with impl side painting.

We have some kind of memory requirement explosion with layer squashing enabled it sounds like, that somehow only affects non-implside negatively. (Maybe it happens to prioritize better for this page under OOM?)
Here is the rough memory usage for the tab

disable layer squashing - ~ 35 MB 
with layer squashing  - ~ 300 MB
Cc: vmp...@chromium.org
Owner: chrishtr@chromium.org
Awesome. Paint slimming will be better, but this sounds like layer explosion.

Comment 10 by kareng@google.com, Sep 9 2014

it doesn't make sense to me. if Disabling impl-side painting is not the CL that's responsible, there's literally nothing else in either of the ranges.
> disabling --enable-impl-side-painting has no effect.

I assumed they meant not passing enable. Does --disable-impl-side-painting cause this to repro on TOT?
To be more precise:

Chrome 37:
No flags : No content is visible, GPU usage = 269MB
--disable-layer-squashing: Page renders correctly. GPU usage = 57.5MB
--enable-impl-side-painting: Page renders correctly. GPU usage = 44.7MB
Both of the above flags together: Still works fine

Chrome 39:
Default flags / --disable-impl-side-painting : Page renders correctly

So there's something about the non-impl-side painting code in 37 that together with layer squashing seems to have this issue. What is also strange is that even though the page uses up to its max memory, not a single tile is visible.  I would expect at least some content to show up. 


Ligi if 36 works fine but 37 is broken, shouldn't the regression range point to 37.xx build? 
I found this broken in M37 branch  , hence attempted a bisect on M38 builds before branch point.
Would this then be a change that we merged into the M37 branch after we branched? 
> I would expect at least some content to show up. 

If you're just inspecting visually, note that the text is white on a white background, so you won't see anything once the background image disappears.  You can use this link with darker text instead:
https://dl.dropboxusercontent.com/spa/jbj423z5m7y8em0/Exports/site_vitrineV4-3/site_vitrineV4-3.html

(it happens on a lot of pages, and usually it is just some of the content that disappears, not all)
Thanks  jonathan for the above testcase.Texts are more visible.

Attempted a manual bisect on M37 branch. This worked till 37.0.2062.15 (Official Build 282180) and is broken from 37.0.2062.16 (Official Build 282473).

Chromium CL - https://chromium.googlesource.com/chromium/src/+log/37.0.2062.15..37.0.2062.16?pretty=fuller&n=10000

Blink CL-
https://chromium.googlesource.com/chromium/blink/+log/0909f1629be1d3f51f4d509da3fbd5c07b1bf0ef..ecf53851e98a88d761599354cd46e4f6843c0000?pretty=fuller&n=10000

Seeing few rendering related changes.
 Issue 412299  has been merged into this issue.
Woo hoo! This CL fixed the issue:

https://codereview.chromium.org/497153003

Don't know why exactly, but it did.

It has already been merged fully into M38.

I tried to merge it for M37 back when it went to stable, but it didn't make it in. (I was also unable to merge it fully cleanly BTW, though the part of it that's in CompositedLayerMapping should not be necessary to fix this particular issue.)

Does this need to be merged for M37? How bad is it?
(FYI I tested that it fixed it with a local revert.)
Cc: amineer@chromium.org
Status: Fixed
I'm going to call this bug fixed, since it is fixed in M38 and M39.
This issue is still happening on Chrome 39 as well as in Chrome Canary 41 inside Postman on Retina displays. The Postman team has been trying to figure out what the issue is but still no luck: https://github.com/a85/POSTMan-Chrome-Extension/issues/705. We tried using a node-webkit wrapper and the problem did not occur there.

https://www.youtube.com/watch?v=rS0n7kfIhDw&feature=youtu.be

Tested on Canary 41. Same issue exists on 39.
Status: Assigned
Re-opening for now.  Chris, can you PTAL and advise if this is the same issue that needs a larger fix, or if a new bug is appropriate?
Status: Fixed
The page I reported initially (ttps://dl.dropboxusercontent.com/spa/jbj423z5m7y8em0/Exports/site_vitrineV4-2/site_vitrineV4-2.html) works fine in Chrome 40.  

#23 based on the video I think what you're experiencing is a different issue (there's no red tile borders to indicate OOM). Most likely you're running into  issue 437905  . 

Sign in to add a comment