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

Issue 122868 link

Starred by 40 users

Issue metadata

Status: Verified
Owner:
OOO until 2019-01-02
Closed: Apr 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 0
Type: Bug

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Compositing problems: flickering screen

Project Member Reported by zelidrag@chromium.org, Apr 10 2012

Issue description

Chrome Version       : 19.0.1084.17
OS Version: 2046.20.0

Open people.com and browser around several pages, reload, click on stuff etc.

Number of pages show what looks like a compositor issue. puneetster@ even managed to get one tab continuously crash.

 
Cc: piman@chromium.org

Comment 2 by piman@chromium.org, Apr 10 2012

I don't think it's at all related to that site.
There's 2 problems at hand, zel experienced what I think is http://code.google.com/p/chromium/issues/detail?id=122582 but what we saw on Puneet's machine was due to a badly handled lost context event.

Comment 3 by piman@chromium.org, Apr 10 2012

I should mention, the latter I think is only on M20.

Comment 4 by piman@chromium.org, Apr 11 2012

Cc: gspencer@chromium.org jamescook@chromium.org nduca@chromium.org jam...@chromium.org
Owner: piman@chromium.org
And it seems to be related to the oom tab discard. So far what I'm seeing:
1- we switch to a new tab, which was discarded previously:
  * we reload the contents
  * we spawn the TabContentsWrapper, the RenderWidgetHost, and its RWVHA, which creates the textures for the backing store
  * we spawn the renderer that starts rendering the frame through the GPU process
2- right away the oom manager is discarding the tab we're switching to.
  * it creates a new dummy TabContentsWrapper, with its RWH and RWHVA, creating a new set of textures
  * it destroys the old TabContentsWrapper, together with the textures.
3- gpu process races, tries to render to the backing store, which was destroyed by 2, causing an error, causing a lost context.
  * there's a separate issue with flash, where recreating the compositor context seems to be causing more lost context issues. I'm trying to track all of that down.

The interesting part is that after the tab was supposedly discarded, the renderer is still alive (it wasn't killed), and AFAICT it renders to the dummy TabContentsWrapper. That seems bogus (as well as the part where it discards the tab we're switching to).

Comment 5 by piman@chromium.org, Apr 11 2012

Note, to get into that state on a lumpy (tune the size for other devices):
mount /tmp -o remount,size=3500M
dd if=/dev/zero of=/tmp/big.file bs=1M count=3000

All your tabs should get discarded now

I had previously disabled extensions and had trouble reproducing this again, but as soon as I re-enabled adblock it happened again.
Cc: creis@chromium.org
You can manually trigger the tab discard behavior by going to chrome://discards/ and clicking the "Discard a tab now" link.  It will discard the one at the bottom of the list (which is the one that will be discarded in a real low-memory situation).

Also, I'm working on a better tab discard behavior as part of  issue 121453  but it may have similar problems.

I wonder if we're not smart enough to immediately deprioritize discard for the tab that's being reloaded.

Comment 7 by piman@chromium.org, Apr 11 2012

Cc: reve...@chromium.org
Issue chromium-os:29276 has been merged into this issue.

Comment 8 by ihf@chromium.org, Apr 11 2012

Cc: krisr@chromium.org rohi...@chromium.org
Issue chromium-os:29340 has been merged into this issue.
Cc: blumberg@chromium.org gwilson@chromium.org
Issue chromium-os:29379 has been merged into this issue.
Would it be helpful if I destroyed the old renderer first and then created the new one?  The order is arbitrary; I assumed it was all asynchronous under the hood.

Comment 11 by piman@chromium.org, Apr 12 2012

 Issue 123071  has been merged into this issue.

Comment 12 by piman@chromium.org, Apr 13 2012

@10: possibly, but I kind of suspect the things that make the renderer use the other tabcontents is a race that would happen anyway, but I really don't know that code.

Comment 13 by piman@chromium.org, Apr 13 2012

Labels: -Mstone-19 Mstone-20
Summary: Compositing problems: flickering screen

Comment 14 by piman@chromium.org, Apr 13 2012

Cc: sonnyrao@chromium.org dgreid@chromium.org gman@chromium.org
Issue chromium-os:29412 has been merged into this issue.

Comment 15 by dharani@google.com, Apr 13 2012

Cc: ddrew@chromium.org
Labels: ReleaseBlock-Beta
Since this is consistently happening in Chrome OS R20, marking it as blocker.

Comment 16 by piman@chromium.org, Apr 13 2012

Issue chrome-os-partner:9045 has been merged into this issue.

Comment 17 by piman@chromium.org, Apr 13 2012

Cc: tturchetto@chromium.org
 Issue 123027  has been merged into this issue.
Labels: Feature-Ash
Labels: -Pri-1 Pri-0
Marking this as P0 since this affects most of Flash sites. Browser restart is required to fix this problem.
If it is a P0 why is it on Mstone-19 and not 20 since it  was reported on  19.0.1084.17
We started seeing this problem on R20.  Issue chromium-os:29340 , Issue chromium-os:29379 ,  Issue chromium-os:29412  

What we are seeing is blinking black/white screen problem. Not sure if flickering issue covers that.

Comment 22 by piman@chromium.org, Apr 16 2012

@20: the original report conflates several issues, some of which affect 19 and are tracked separately. This one only affect 20.

@21: yes same thing.

Comment 23 by piman@chromium.org, Apr 17 2012

Issue chromium-os:29530 has been merged into this issue.

Comment 24 by piman@chromium.org, Apr 17 2012

https://chromiumcodereview.appspot.com/10103021/ will fix the flickering issue in user-visible cases, but the underlying issues (lost context recovery) will still need some love.

Comment 25 by piman@chromium.org, Apr 17 2012

Labels: -Feature-Ash Internals-Aura
Project Member

Comment 26 by bugdroid1@chromium.org, Apr 17 2012

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=132638

------------------------------------------------------------------------
r132638 | piman@chromium.org | Tue Apr 17 13:36:49 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/common/gpu/texture_image_transport_surface.cc?r1=132638&r2=132637&pathrev=132638
 M http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/service/gles2_cmd_decoder.cc?r1=132638&r2=132637&pathrev=132638
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/common/gpu/texture_image_transport_surface.h?r1=132638&r2=132637&pathrev=132638

aura/texture transport: Keep ref to texture infos to avoid races with the UI

In some cases, the UI may destroy the textures the renderer is rendering into
before the renderer has a chance to finish.
This patch makes it so that we avoid generating a lost context event in the
page that is closing, because we can't recover correctly in the other pages in
the same renderer process.

This also adds logging so that we can audit all cases of lost context.

BUG= 122868 
TEST=run aura chrome, open and close tabs (from the same process), observe no
flashing and no mention of a lost context.


Review URL: http://codereview.chromium.org/10103021
------------------------------------------------------------------------
Project Member

Comment 27 by bugdroid1@chromium.org, Apr 17 2012

Labels: merge-merged-1105
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=132650

------------------------------------------------------------------------
r132650 | ddrew@chromium.org | Tue Apr 17 14:19:30 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/1105/src/content/common/gpu/texture_image_transport_surface.cc?r1=132650&r2=132649&pathrev=132650
 M http://src.chromium.org/viewvc/chrome/branches/1105/src/gpu/command_buffer/service/gles2_cmd_decoder.cc?r1=132650&r2=132649&pathrev=132650
 M http://src.chromium.org/viewvc/chrome/branches/1105/src/content/common/gpu/texture_image_transport_surface.h?r1=132650&r2=132649&pathrev=132650

Merge 132638 - aura/texture transport: Keep ref to texture infos to avoid races with the UI

In some cases, the UI may destroy the textures the renderer is rendering into
before the renderer has a chance to finish.
This patch makes it so that we avoid generating a lost context event in the
page that is closing, because we can't recover correctly in the other pages in
the same renderer process.

This also adds logging so that we can audit all cases of lost context.

BUG= 122868 
TEST=run aura chrome, open and close tabs (from the same process), observe no
flashing and no mention of a lost context.


Review URL: http://codereview.chromium.org/10103021

TBR=piman@chromium.org
Review URL: https://chromiumcodereview.appspot.com/10035008
------------------------------------------------------------------------

Comment 28 by piman@chromium.org, Apr 17 2012

Status: Fixed
Context lost issues tracked separately in http://code.google.com/p/chromium/issues/detail?id=123174 , so I can close this.
Status: Verified
2164.0.0

Not seeing the blinking problem.

Comment 30 by piman@chromium.org, Apr 20 2012

Cc: rahulrc@chromium.org
Issue chromium-os:29226 has been merged into this issue.
Project Member

Comment 31 by bugdroid1@chromium.org, Apr 27 2012

Labels: merge-merged-1084
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=134340

------------------------------------------------------------------------
r134340 | piman@chromium.org | Fri Apr 27 13:34:01 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/1084/src/gpu/command_buffer/client/gles2_implementation.cc?r1=134340&r2=134339&pathrev=134340
 M http://src.chromium.org/viewvc/chrome/branches/1084/src/content/common/gpu/texture_image_transport_surface.cc?r1=134340&r2=134339&pathrev=134340
 M http://src.chromium.org/viewvc/chrome/branches/1084/src/gpu/command_buffer/service/gles2_cmd_decoder.cc?r1=134340&r2=134339&pathrev=134340
 M http://src.chromium.org/viewvc/chrome/branches/1084/src/content/browser/renderer_host/image_transport_factory.cc?r1=134340&r2=134339&pathrev=134340
 M http://src.chromium.org/viewvc/chrome/branches/1084/src/content/common/gpu/texture_image_transport_surface.h?r1=134340&r2=134339&pathrev=134340
 M http://src.chromium.org/viewvc/chrome/branches/1084/src/content/common/gpu/client/gl_helper.cc?r1=134340&r2=134339&pathrev=134340

Backport to R19 of r132638 r133017 r133579 r133732

texture_image_transport: have a current context when we're releasing textures

In some cases, the TextureImageTransportSurface may get destroyed when no
context is current. When that's the case, glDeleteTextures becomes a noop and we
leak them.

BUG= 123933 
TEST=manual

Review URL: http://codereview.chromium.org/10200012


Unbind texture from all texture units when deleting it.

BUG=None
TEST=None

Review URL: http://codereview.chromium.org/10179006


aura: Add flush() to make sure delete operations make it through when we intend.

Resource deletion doesn't force a flush, so for textures that are deleted on a
little-used shared context, the delete command may sit in the command buffer for
arbitrary long.

This fixes it.

BUG= 123933 
TEST=chrome/aura, open many tabs, close all of them, check that GPU memory is reclaimed.

Review URL: http://codereview.chromium.org/10078002


Conflicts:

	content/common/gpu/client/gl_helper.cc

aura/texture transport: Keep ref to texture infos to avoid races with the UI

In some cases, the UI may destroy the textures the renderer is rendering into
before the renderer has a chance to finish.
This patch makes it so that we avoid generating a lost context event in the
page that is closing, because we can't recover correctly in the other pages in
the same renderer process.

This also adds logging so that we can audit all cases of lost context.

BUG= 122868 
TEST=run aura chrome, open and close tabs (from the same process), observe no
flashing and no mention of a lost context.

Review URL: http://codereview.chromium.org/10103021


Review URL: https://chromiumcodereview.appspot.com/10214014
------------------------------------------------------------------------
Issue seems to have disappeared in the latest chrome os dev build 20.0.1116.0 - platform 2199.0.0
Cc: davemoore@chromium.org
 Issue 124840  has been merged into this issue.
Project Member

Comment 34 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 35 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-UI -Mstone-20 -Feature-GPU-Compositing -Internals-Aura Cr-Internals-Aura Cr-Internals-GPU-Compositing M-20 Cr-UI
Project Member

Comment 36 by bugdroid1@chromium.org, Mar 14 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member

Comment 37 by bugdroid1@chromium.org, Apr 5 2013

Labels: -Cr-Internals-GPU-Compositing Cr-Internals-Compositing

Sign in to add a comment