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

Issue 145600 link

Starred by 107 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: Fixed
Owner:
Closed: Sep 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug

Blocked on:
issue 147737

Blocking:
issue 469979

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

Chromium UI freezes on Linux

Project Member Reported by jchaffraix@chromium.org, Aug 29 2012

Issue description

Version: 23.0.1246.0 (Official Build 153452) dev
OS: Linux Precise (Goobuntu)

What steps will reproduce the problem?

Difficult to say, opening a new tab triggers the issue but not always. I usually have > 30 tabs opened which shouldn't help. During my gardening shift, it happened frequently, usually more than once per hour.

What's the issue?

Chromium UI freezes: you can't switch tabs, close tabs, ... However minimizing and closing still work. Restarting Chromium makes the problem disappear. Minimizing & maximizing again also helps. Philip (CC'ed) also experienced a similar issue.

It only impacts the current window and the other windows are safe.
 
Showing comments 73 - 172 of 172 Older
Project Member

Comment 73 by bugdroid1@chromium.org, Oct 10 2012

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

------------------------------------------------------------------------
r161150 | ccameron@chromium.org | 2012-10-10T19:23:49.836442Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/gpu/software_rendering_list.json?r1=161150&r2=161149&pathrev=161150

Blacklist video and flash acceleration on NVIDIA Linux drivers.

If you create a context when you are low memory, this context may get
into a bad state where geomerty is corrupted and the screen takes seconds
to paint.  The context remains in this state until it is destroyed, even
if more memory comes available.

This disabled accelerated compositing to limit the exposure to this bug.

I plan to integrate this into M23.  We shouldn't re-enable accelerated
compositing until we have a more robust workaround, or NVIDIA fixes the
context creation bug.

BUG= 145600 

Review URL: https://chromiumcodereview.appspot.com/11095006
------------------------------------------------------------------------
Cc: flackr@chromium.org rbyers@chromium.org jln@chromium.org
Issue 143977 has been merged into this issue.
Labels: -MovedFrom-23 -Mstone-24 Mstone-23 Merge-Requested
Marking merge-requested.

Comment 76 by kareng@google.com, Oct 18 2012

Labels: -Merge-Requested Merge-Approved
if i am reading this right and it's linux only, you're approved for r161150. pls ping me if it's not linux only.
Just wanted to confirm that the blacklisting is available in the current Chrome Beta for Linux?  Also, regarding the Nvidia "context bug" was wondering if Nvidia's recent addition of http://www.nvidia.com/object/linux-display-amd64-310.14-driver.html their 310.14 driver has any potential fixes or workarounds.   
Note the r161150 broke the WebRTC demo app (apprtc.appspot.com), which uses webkit-transition, webkit-transform etc.

I created crbug/156555 for it. Any suggest or how to workaround this?
Cc: ronghuawu@chromium.org
I think that  issue 156555  isn't actually a bug caused by this (but rather a bug in the accelerated path that was being relied on).  We're double-checking that right now (at the very least, we should be able to find a workaround for GVC).

I'm going to wait for a resolution on  issue 156555  to drover this in to M23 (hopefully won't take more than a day).
Project Member

Comment 81 by bugdroid1@chromium.org, Oct 18 2012

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

------------------------------------------------------------------------
r162846 | ccameron@chromium.org | 2012-10-18T23:46:17.820951Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1271/src/content/browser/gpu/software_rendering_list.json?r1=162846&r2=162845&pathrev=162846

Merge 161150 - Blacklist video and flash acceleration on NVIDIA Linux drivers.

If you create a context when you are low memory, this context may get
into a bad state where geomerty is corrupted and the screen takes seconds
to paint.  The context remains in this state until it is destroyed, even
if more memory comes available.

This disabled accelerated compositing to limit the exposure to this bug.

I plan to integrate this into M23.  We shouldn't re-enable accelerated
compositing until we have a more robust workaround, or NVIDIA fixes the
context creation bug.

BUG= 145600 

Review URL: https://chromiumcodereview.appspot.com/11095006

TBR=ccameron@chromium.org
Review URL: https://codereview.chromium.org/11186066
------------------------------------------------------------------------
Labels: -Mstone-23 Mstone-24
Merged into M23.  There's lots to do for this for M24, moving to Mstone-24.
Labels: not-webrtc

Comment 84 by oleg@chromium.org, Oct 26 2012

Cc: oleg@chromium.org
There's still too much to do for this to put in a release branch.  Let's keep the aggressive blacklisting for M24 and do the context killing/virtualization in M25.
I have the problem that if I keep Chrome open overnight and come back the next morning, I am unable to open a new tab for some time. Trying to open a new tab shows only the close button and an empty browser window (see attached screenshot). When trying to navigate to a webpage nothing happens. See second screenshot for how it looks when closing the tab again.

The existing tabs continue to work.

I usually start Firefox to open the page I wanted to see, and after a few minutes, Chrome works again as normal.
chrome2.png
12.7 KB View Download
chrome.png
13.7 KB View Download
Cc: e...@chromium.org
Screenshots in #86 don't look *at all* like what would happen with a GPU hang:
- Other apps work fine, so it's not like X (or the GPU hardware) is stuck
- The UI is stuck, but on linux, that currently doesn't hit the GPU
- It looks like the UI started doing some things (created a new tab in the tab strip) but got stuck quickly

It's most likely something going on in the browser process - a thread being stuck for some reason, like a file thread, and the UI waiting on it.

One thing you could do that would be very useful if you repro this everyday is this:
- make sure you have crash reporting enabled (from the settings page, in "Show advanced settings", check the "Automatically send usage statistics and crash reports to Google" box)
- when chrome gets stuck, kill the browser process with a segv to generate a crash:
  * find the browser process with 'ps ux |grep chrome/chrome |grep -v type=', taking the line that has the lowest pid
  * kill it with 'kill -11 $pid' where $pid is the pid of the browser process (as found above)
- reopen chrome, then go to about:crashes and report the crash ID that was generated.

This should be able to tell us where chrome gets stuck.

Comment 88 by Deleted ...@, Nov 8 2012

I believe this thread concerns the cause of the problem I am having with Chrome. At some point during use, Chrome stops responding and _everything_else_ on my system becomes inaccessible, probably because the graphics environment is stuck. I can log in from another system but I cannot kill chrome (not with -9 or -11). Here is the process entry which I cannot kill.

19825 ?        D      0:42 /opt/google/chrome/chrome --type=gpu-process --channel=19726.7.529504134 --gpu-vendor-id=0x1002 --gpu-device-id=0x683d --gpu-driver-vendor=ATI / AMD --gpu-driver-version=8.96.7

Once Chrome gets stuck mouse and keyboard have no effect. I have only been able to release it via reboot.

< david

This issue was specific to NVIDIA -- it's interesting that you are hitting a similar issue with an AMD card.  Can you attach an about:gpu?

Comment 90 by Deleted ...@, Nov 8 2012

The output of about:gpu is attached to this comment. Clearly I thought this was a more general GPU thread. Certainly, my issue a) clearly Chrome and b) possibly gpu related. I now realize this thread led me to think my problem is GPU. It may be but I need to consider other possible causes.

For the time being, alas, Chrome is too dangerous for me to use other than for testing.
chrome___gpu.pdf
95.0 KB Download

Comment 91 by kbr@chromium.org, Nov 8 2012

@dmischel, @ccameron: It's a bug in Chrome that it attempts to use the GPU at all with AMD's 8.96.7 drivers -- the blacklisting code was recently fixed by @zmo.

It would be helpful to know if you upgrade to a more recent driver whether the problems persist.

Comment 92 by Deleted ...@, Nov 8 2012

Thanks for the suggestion. I have upgraded to 9.02, which I got from the AMD website and appears to be the most recent applicable to my system. I will retry Chrome and see what happens.
Cc: gman@chromium.org
Labels: -Mstone-24 Mstone-25
Moving to M25 as that's the first release where we should be able to roll out GL context virtualization.

Comment 94 by sasy...@gmail.com, Nov 15 2012

Idk it's the same bug but I encounter a similar issue with Ubuntu 12.10 using the open source Nouveau driver. When I create a new tab, the whole browser freezes for a few seconds . and then I enter a url it freezes again and remains in that state till it completely renders the page. there is no high CPU usage while this happens and It affects my desktop environment too. My GPU is GeForce 9600M.
I also experienced this on ubuntu 12.04 when I updated Mesa stack to 9.0.
No sign of this issue on proprietary Nvidia 310.14 driver.

Comment 95 by Deleted ...@, Nov 16 2012

Follow up to Comment 92: After upgrading the AMD driver I have slowly expanded my use of Chrome. No further problems have taken place so I conclude the driver was the problem and now it is fixed. Again, this is AMD 9.02. Thanks, all, for your helpful suggestions.
To #94 (sasy360), nouveau is blacklisted (no GPU acceleration is allowed) because of stability issues (see discussion in  issue 94103 ).
I have a change coming through the commit queue to allow explicitly creating and destroying GLX windows independent of the X window for the tab.

I started adding glXCreateWindow/glXDestroyWindow pairs, and everything blew up. Stephane, Antoine, and I think that this is a bug in the NVIDIA GL drivers. I've attached a reduced test case which I'm going to test on other drivers, then follow up with NVIDIA.
glx-window.c
3.7 KB View Download
Project Member

Comment 98 by bugdroid1@chromium.org, Dec 7 2012

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

------------------------------------------------------------------------
r171679 | ccameron@chromium.org | 2012-12-07T01:36:45.071825Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/gl/gl_surface_glx.cc?r1=171679&r2=171678&pathrev=171679
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/gl/gl_surface_glx.h?r1=171679&r2=171678&pathrev=171679
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/gl/gl_context_glx.cc?r1=171679&r2=171678&pathrev=171679

Explicitly create the GLX window for onscreen surfaces.

Always use glXCreateContextAttribsARB to create GLX contexts.

This will allow us to explicitly destroy hibernated GLX windows, which will hopefully plug some GPU memory leaks that were causing instability.

BUG= 145600 


Review URL: https://chromiumcodereview.appspot.com/11467008
------------------------------------------------------------------------
The situation here is pretty bad. Despite changing adding glXCreate/DestroyWindow calls, it looks like the NVIDIA driver attaches the GLXWindow's resources to the parent X window, and never frees them.

The effect of this is the same as the IOSurface leak that we found on OS X. We run out of VRAM after a handful of fullscreen tabs are created.

I've created a stand-alone program (glx-window-leak.c) that uses GLX the same way that Chrome does, and quickly runs out of VRAM.

I will bring this up with the NVIDIA driver team and see if there is a special incantation that we can do to say "really, please, I want this GLXWindow deleted, and I'm serious about it". If not, we'll have to wait for a driver fix or Aura (of which I think Aura will win the race) before enabling force-compositing-mode on NVIDIA-Linux.

Also of note is that even if we just have 1 GL context (by virtualization), we still hit the same issue.
Project Member

Comment 100 by bugdroid1@chromium.org, Dec 7 2012

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

------------------------------------------------------------------------
r171698 | xiyuan@chromium.org | 2012-12-07T05:56:34.474448Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/gl/gl_surface_glx.cc?r1=171698&r2=171697&pathrev=171698
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/gl/gl_surface_glx.h?r1=171698&r2=171697&pathrev=171698
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/gl/gl_context_glx.cc?r1=171698&r2=171697&pathrev=171698

Revert 171679
> Explicitly create the GLX window for onscreen surfaces.
> 
> Always use glXCreateContextAttribsARB to create GLX contexts.
> 
> This will allow us to explicitly destroy hibernated GLX windows, which will hopefully plug some GPU memory leaks that were causing instability.
> 
> BUG= 145600 
> 
> 
> Review URL: https://chromiumcodereview.appspot.com/11467008

TBR=ccameron@chromium.org
Review URL: https://codereview.chromium.org/11472019
------------------------------------------------------------------------
Project Member

Comment 101 by bugdroid1@chromium.org, Dec 10 2012

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

------------------------------------------------------------------------
r172122 | ccameron@chromium.org | 2012-12-10T20:13:35.157743Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/gl/gl_surface_glx.cc?r1=172122&r2=172121&pathrev=172122
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/gl/gl_surface_glx.h?r1=172122&r2=172121&pathrev=172122
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/gl/gl_context_glx.cc?r1=172122&r2=172121&pathrev=172122

Always use either glXCreateNewContext or glXCreateContextAttribsARB for GLX

Explicitly create the GLX window for onscreen surfaces.

Use glXCreateContextAttribsARB to create GLX contexts when GLX_ARB_create_context is supported, otherwise use glXCreateNewContext.

This will allow us to explicitly destroy hibernated GLX windows, which will hopefully plug some GPU memory leaks that were causing instability.

BUG= 145600 


Review URL: https://chromiumcodereview.appspot.com/11474045
------------------------------------------------------------------------
@'ccameron@chromium.org': when is r=172122 going to be packaged into 'google-chrome-beta' or 'google-chrome-unstable'.  I have the Nvidia 310.14 drivers and I would be very interested in testing it out given the high volume of fixes Nvidia has delivered in the 310.xx series...






I've followed up with NVIDIA, and indeed there exists a GPU memory leak with NVIDIA Linux GLX drivers. The leak is present through the 310 driver series. Until that is fixed (or we can find a workaround, or we no longer have a GLX window per tab), force-compositing-mode will have to stay off.

The NVIDIA Reference number is #121210-000205.
Labels: -Mstone-25 Mstone-26
@ccameron : thanks for following up.  Since a true fix for this issue doesn't seem possible in the M25 timeframe, I'm pushing out to M26. In the meantime, we're keeping force-compositing-mode off on linux.

Comment 105 by hymie@google.com, Dec 28 2012

I have the same (longstanding) problem as #86 - I have about half a dozen chrome windows each displaying some tens of tabs. It works fine during the day, but left overnight or over weekends, chrome shows high memory usage (using top and ordering by size finds the largest chrome process using some 6GB and sometimes much more). Switching between tabs works in that the old contents redraw, but no active elements inside the pages respond to clicks and no new content refreshes. Opening a new tab looks just like #86. The task manager can usually be started from the indicator, and it shows a large amount of "Private Memory" being used by the task named "Browser". Trying "Exit" from the indicator does nothing. Also, the "Let Google Chrome Run In The Background" toggle is displayed unchecked at this point although it normally displays as checked. Eventually I give up waiting and kill -9 that large process, and it makes all of chrome die.
For the time being do I have to keep using the command line switch '--disable-accelerated-compositing'

Does the following change mean that this fix will probably land in M26?

Linux x64 (AMD64/EM64T) Display Driver
Version	 313.09 - BETA

"Added unofficial GLX protocol support (i.e for GLX indirect rendering) for the following extension and core commands.
ARB_vertex_array_object
OpenGL 3.0 commands ClearBufferfi, ClearBufferfv, ClearBufferiv, ClearBufferuiv and GetStringi."

Cc: mbollu@chromium.org
As reported by bug filer chrome window suddenly freezes on Chrome 26.0.1377.0 dev. The steps are similar to steps to reproduce.
This will not be fixed for M26.  The root issue is that NV drivers lock up under heavy memory usage.  This is further compounded by a GLX memory leak in the NV drivers.  Until that bug is fixed, or we transition to Aura, we will have to keep NV blacklisted (and even then, any use of GL is dangerous).
Labels: -Mstone-26
Status: ExternalDependency
Since we're reliant on Nvidia driver changes, marking external dependency then. Meanwhile we'll continue to blacklist FCM on these Nvidia drivers.
We'll be able to enable FCM when Aura ships, because (IIUC) that will only have 1 GLX window, which will sidestep NVIDIA's bug.
@ccameron - with Aura there will still be 1 GLX window per chrome browser window as well as one per menu/other things that require a top-level window.
That should be okay -- as long as we have a reasonable number of GLX windows (not 1 per tab), and the GLX windows' lifetimes line up with their owning X windows' lifetimes, we should be in good shape.

Of course, the NV OOM behavior is still unstable and needs to be addressed, but getting rid of the 1 GLX window per tab allocation (which is huge) will go some way towards keeping the driver out of that territory.
Project Member

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

Labels: -Area-UI -Feature-GPU Cr-Internals-GPU Cr-UI
Confirmed with chrome 27 !!!!!!

In chrome 26 I've partially solved the problem by using the command line option
> google-chrome  --disable-accelerated-compositing

But in chrome 27 this option is no longer available (or don't have effect on this problem)

@ccameron, the latest Nvidia Certified 319.17 driver seems to address this issue directly, is there a way you can verify?

Changelog:
"Fixed a memory leak that occurred when destroying a GLX window but not its associated X window."

http://us.download.nvidia.com/XFree86/Linux-x86_64/319.17/README/index.html
I'm using the nvidia driver 319.17 and the bug is always there  
> "Fixed a memory leak that occurred when destroying a GLX window but not its associated X window."

Awesome! I'll see if this allows us to free up the GLX windows.

It seems that their low-memory handling is still unstable, but at least this gives us a fighting chance.

Comment 118 by misch@google.com, May 24 2013

If newer NVIDIA drivers improve the situation please update this bug with details. (the driver version; what actually improved; ...)
@ccameron, what "standard" testing procedure would you want testers to utilize to verify whether the 219 series driver makes a difference?
I'm going to verify is that we can destroy GLX windows for backgrounded tabs to save on memory, without affecting the X windows. The code to do that doesn't exist because it caused X errors on older drivers.
This won't make it to M28, but M29 is likely (on NV drivers with the GLX issue fixed).

Comment 122 by misch@google.com, May 29 2013

@ccameron:
Can you go a little bit more into detail here?
* About which NVIDIA driver versions are we talking here? (I assume newer than 319.17)
* What will happen with older NVIDIA drivers? Will they be blacklisted in Chrome 29?
* How exactly will the behavior of Chrome change?

Comment 123 by kbr@chromium.org, Jul 10 2013

Cc: misch@google.com
 Issue 241290  has been merged into this issue.
Besides checking on the new driver, I think there may be a simple workaround consisting in creating an X window in the GPU process (in the NativeViewGLSurfaceGLX), so that we can destroy it when we want to release the surface.

Comment 125 by misch@google.com, Jul 16 2013

Is there any ETA or at least an update on this issue?
Currently our only option is to replace video cards if people are running out of video memory. Cards with 256 MB will be replaced on sight and some people also kill cards with 512 MB or even 1 GB of memory with their usage...
Owner: ----
Removing myself because I'm not actively working this.
 Issue 133185  has been merged into this issue.
Owner: ccameron@chromium.org
Antoine suggested trying to work around this issue by creating a child X window and creating the GLX window there (and then destroying both the child and the GLX window).

I tried this on an r310 driver in a standalone app (see the attached glx-window-create-destroy-subwindow.c), and it looks like it isn't broken! I'll try to plug this in.

Also of note is that I found that we're using about 25-50% more memory on Linux than we need to -- I have a patch out to get rid of that.
Actually attaching the test app.
glx-window-create-destroy-subwindow.c
4.6 KB View Download

Comment 130 by misch@google.com, Aug 19 2013

Thanks Christopher!
In which release do you think this fix / these fixes will be? M31?
Labels: M-31
This will be done for M31, barring unforeseen issues.
Project Member

Comment 132 by bugdroid1@chromium.org, Aug 21 2013

------------------------------------------------------------------------
r218597 | ccameron@chromium.org | 2013-08-21T01:44:40.174512Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/common/gpu/gpu_memory_manager.cc?r1=218597&r2=218596&pathrev=218597

Minimize GPU memory usage on Linux

BUG= 145600 

Review URL: https://chromiumcodereview.appspot.com/22923016
------------------------------------------------------------------------
Project Member

Comment 133 by bugdroid1@chromium.org, Sep 7 2013

------------------------------------------------------------------------
r221846 | sadrul@chromium.org | 2013-09-07T01:13:39.024048Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump_aurax11.cc?r1=221846&r2=221845&pathrev=221846
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump_aurax11.h?r1=221846&r2=221845&pathrev=221846
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump_gtk.cc?r1=221846&r2=221845&pathrev=221846
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump_gtk.h?r1=221846&r2=221845&pathrev=221846
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_loop.cc?r1=221846&r2=221845&pathrev=221846
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_loop.h?r1=221846&r2=221845&pathrev=221846
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/run_loop.cc?r1=221846&r2=221845&pathrev=221846
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump_glib.cc?r1=221846&r2=221845&pathrev=221846
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/run_loop.h?r1=221846&r2=221845&pathrev=221846
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump_glib.h?r1=221846&r2=221845&pathrev=221846

gtk: Some code cleanup for the message-pump.

GTK message-pump defines its own observer, but it has the same name as the
message-pump observers used in other platforms. So rename the GTK version
to MessagePumpGdkObserver.

Also, GTK version of message-pump dispatcher is never used, so get rid of
that.

BUG= 145600 
R=piman@chromium.org, thakis@chromium.org

Review URL: https://codereview.chromium.org/23537016
------------------------------------------------------------------------
Project Member

Comment 134 by bugdroid1@chromium.org, Sep 7 2013

------------------------------------------------------------------------
r221873 | sadrul@chromium.org | 2013-09-07T03:21:04.941620Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/views/widget/desktop_aura/x11_desktop_window_move_client.cc?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/base/x/selection_requestor.cc?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/aura/env.cc?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/base.gyp?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/power_save_blocker_x11.cc?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/chromeos/display/real_output_configurator_delegate.cc?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/views/widget/desktop_aura/x11_whole_screen_move_loop.cc?r1=221873&r2=221872&pathrev=221873
   A http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump_x11.cc?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/aura/root_window_host_x11.cc?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_loop.h?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/views/widget/desktop_aura/desktop_root_window_host_x11.cc?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/aura/bench/bench_main.cc?r1=221873&r2=221872&pathrev=221873
   A http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump_x11.h?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/base.gypi?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/views/widget/desktop_aura/desktop_drag_drop_client_aurax11.cc?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/aura/test/ui_controls_factory_aurax11.cc?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/views/widget/desktop_aura/x11_desktop_handler.cc?r1=221873&r2=221872&pathrev=221873
   D http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump_aurax11.cc?r1=221873&r2=221872&pathrev=221873
   D http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump_aurax11.h?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/chromeos/display/output_util.cc?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/base/dragdrop/os_exchange_data_provider_aurax11.cc?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/aura/demo/demo_main.cc?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/ash/shell.cc?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/views/widget/desktop_aura/x11_window_event_filter.cc?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/ash/display/mirror_window_controller.cc?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump_observer.h?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/base/clipboard/clipboard_aurax11.cc?r1=221873&r2=221872&pathrev=221873
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/base/x/events_x.cc?r1=221873&r2=221872&pathrev=221873

gtk: Allow building both the X11 and Gtk message-pumps for gtk.

This patch allows both the X11 and the Gtk message-pumps to be built
in a linux-gtk build. A subsequent patch will use the X11 message-pump
for the GPU process, while continue to use the Gtk message-pump for the
browser process.

BUG= 145600 
R=ccameron@chromium.org, oshima@chromium.org, piman@chromium.org, thakis@chromium.org

Review URL: https://codereview.chromium.org/23880006
------------------------------------------------------------------------
Project Member

Comment 135 by bugdroid1@chromium.org, Sep 11 2013

------------------------------------------------------------------------
r222470 | ccameron@chromium.org | 2013-09-11T04:20:03.720235Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_loop.cc?r1=222470&r2=222469&pathrev=222470
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/gpu/gpu_main.cc?r1=222470&r2=222469&pathrev=222470
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump_x11.cc?r1=222470&r2=222469&pathrev=222470
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_loop.h?r1=222470&r2=222469&pathrev=222470
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump_x11.h?r1=222470&r2=222469&pathrev=222470
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/custom_handlers/protocol_handler_registry_unittest.cc?r1=222470&r2=222469&pathrev=222470

Use an X event loop in the GPU process on Linux.

In future patches, X windows will be created in the GPU
process, and events sent to these windows will need to
be forwarded to their parent windows.

Linux uses GTK as the default UI event loop type, but
GTK is not in the GPU process, so the X11 event loop
type is used instead.

BUG= 145600 

Review URL: https://chromiumcodereview.appspot.com/23477050
------------------------------------------------------------------------
Project Member

Comment 136 by bugdroid1@chromium.org, Sep 11 2013

------------------------------------------------------------------------
r222589 | noamsml@chromium.org | 2013-09-11T17:52:41.826229Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_loop.cc?r1=222589&r2=222588&pathrev=222589
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/gpu/gpu_main.cc?r1=222589&r2=222588&pathrev=222589
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump_x11.cc?r1=222589&r2=222588&pathrev=222589
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_loop.h?r1=222589&r2=222588&pathrev=222589
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump_x11.h?r1=222589&r2=222588&pathrev=222589
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/custom_handlers/protocol_handler_registry_unittest.cc?r1=222589&r2=222588&pathrev=222589

Revert 222470 "Use an X event loop in the GPU process on Linux." This is to
check if it adds an unexpected dependency on libxi6.

> Use an X event loop in the GPU process on Linux.
>
> In future patches, X windows will be created in the GPU
> process, and events sent to these windows will need to
> be forwarded to their parent windows.
>
> Linux uses GTK as the default UI event loop type, but
> GTK is not in the GPU process, so the X11 event loop
> type is used instead.
>
> BUG= 145600 
>
> Review URL: https://chromiumcodereview.appspot.com/23477050

TBR=ccameron@chromium.org

Review URL: https://codereview.chromium.org/24114002
------------------------------------------------------------------------
Project Member

Comment 137 by bugdroid1@chromium.org, Sep 12 2013

------------------------------------------------------------------------
r222689 | ccameron@chromium.org | 2013-09-12T01:12:08.723699Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_loop.h?r1=222689&r2=222688&pathrev=222689
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump_x11.h?r1=222689&r2=222688&pathrev=222689
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/installer/linux/rpm/expected_deps_i386?r1=222689&r2=222688&pathrev=222689
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/installer/linux/rpm/expected_deps_x86_64?r1=222689&r2=222688&pathrev=222689
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/custom_handlers/protocol_handler_registry_unittest.cc?r1=222689&r2=222688&pathrev=222689
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/installer/linux/debian/expected_deps?r1=222689&r2=222688&pathrev=222689
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_loop.cc?r1=222689&r2=222688&pathrev=222689
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/gpu/gpu_main.cc?r1=222689&r2=222688&pathrev=222689
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump_x11.cc?r1=222689&r2=222688&pathrev=222689

Use an X event loop in the GPU process on Linux.

In future patches, X windows will be created in the GPU
process, and events sent to these windows will need to
be forwarded to their parent windows.

Linux uses GTK as the default UI event loop type, but
GTK is not in the GPU process, so the X11 event loop
type is used instead.

Update package dependencies.

BUG= 145600 
TBR=thakis, piman

Review URL: https://chromiumcodereview.appspot.com/23710029
------------------------------------------------------------------------
Project Member

Comment 138 by bugdroid1@chromium.org, Sep 12 2013

------------------------------------------------------------------------
r222694 | dalecurtis@google.com | 2013-09-12T01:49:29.868522Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_loop.cc?r1=222694&r2=222693&pathrev=222694
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/gpu/gpu_main.cc?r1=222694&r2=222693&pathrev=222694
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump_x11.cc?r1=222694&r2=222693&pathrev=222694
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_loop.h?r1=222694&r2=222693&pathrev=222694
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump_x11.h?r1=222694&r2=222693&pathrev=222694
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/installer/linux/rpm/expected_deps_i386?r1=222694&r2=222693&pathrev=222694
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/installer/linux/rpm/expected_deps_x86_64?r1=222694&r2=222693&pathrev=222694
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/custom_handlers/protocol_handler_registry_unittest.cc?r1=222694&r2=222693&pathrev=222694
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/installer/linux/debian/expected_deps?r1=222694&r2=222693&pathrev=222694

Revert 222689 "Use an X event loop in the GPU process on Linux."

> Use an X event loop in the GPU process on Linux.
> 
> In future patches, X windows will be created in the GPU
> process, and events sent to these windows will need to
> be forwarded to their parent windows.
> 
> Linux uses GTK as the default UI event loop type, but
> GTK is not in the GPU process, so the X11 event loop
> type is used instead.
> 
> Update package dependencies.
> 
> BUG= 145600 
> TBR=thakis, piman
> 
> Review URL: https://chromiumcodereview.appspot.com/23710029

Broke nacl-sizes:
PERF_REGRESS: nacl_helper-text/text (0.11%), nacl_helper-text/text (0.11%)
http://build.chromium.org/p/chromium/buildstatus?builder=Linux%20x64&number=55508

Please add a suppression or remove the inclusion from nacl_helper.

TBR=ccameron@chromium.org

Review URL: https://codereview.chromium.org/23620042
------------------------------------------------------------------------
Project Member

Comment 139 by bugdroid1@chromium.org, Sep 12 2013

------------------------------------------------------------------------
r222894 | ccameron@chromium.org | 2013-09-12T22:51:10.714604Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/installer/linux/debian/expected_deps?r1=222894&r2=222893&pathrev=222894
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_loop.cc?r1=222894&r2=222893&pathrev=222894
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/gpu/gpu_main.cc?r1=222894&r2=222893&pathrev=222894
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump_x11.cc?r1=222894&r2=222893&pathrev=222894
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_loop.h?r1=222894&r2=222893&pathrev=222894
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump_x11.h?r1=222894&r2=222893&pathrev=222894
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/installer/linux/rpm/expected_deps_i386?r1=222894&r2=222893&pathrev=222894
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/installer/linux/rpm/expected_deps_x86_64?r1=222894&r2=222893&pathrev=222894
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/custom_handlers/protocol_handler_registry_unittest.cc?r1=222894&r2=222893&pathrev=222894

Use an X event loop in the GPU process on Linux.

In future patches, X windows will be created in the GPU
process, and events sent to these windows will need to
be forwarded to their parent windows.

Linux uses GTK as the default UI event loop type, but
GTK is not in the GPU process, so the X11 event loop
type is used instead.

Update package dependencies.

This will cause a regression in nacl_helper-text/text. Test
expectations will need to be updated.

BUG= 145600 
TBR=thakis, piman, mmoss, erg

Review URL: https://chromiumcodereview.appspot.com/23530050
------------------------------------------------------------------------
Project Member

Comment 140 by bugdroid1@chromium.org, Sep 12 2013

------------------------------------------------------------------------
r222912 | ccameron@chromium.org | 2013-09-12T23:40:13.028132Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/tools/perf_expectations/perf_expectations.json?r1=222912&r2=222911&pathrev=222912

Update nacl_helper-text expectations.

Failure at: http://build.chromium.org/p/chromium/builders/Linux%20x64/builds/55550

BUG= 145600 
TBR=pasko

Review URL: https://codereview.chromium.org/23451056
------------------------------------------------------------------------
Project Member

Comment 141 by bugdroid1@chromium.org, Sep 13 2013

------------------------------------------------------------------------
r223148 | ccameron@chromium.org | 2013-09-13T22:39:54.332056Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/gl/gl_surface_glx.h?r1=223148&r2=223147&pathrev=223148
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/common/gpu/gpu_memory_manager.h?r1=223148&r2=223147&pathrev=223148
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/gl/gl_surface_glx.cc?r1=223148&r2=223147&pathrev=223148

Destroy GLX windows when they are backgrounded

Because GLX windows cannot be destroyed separately from their
X windows on all platforms, create a separate child X window to use
with GLX. Destroy this child X window when the backbuffer for the
window is no longer needed.

Because the GL surface may need to be made current while its
backbuffer is destroyed (e.g, to destroy GL resources for a
backgrounded tab), create a dummy 1x1 GL surface which is
never destroyed and can always be made current.

Because the child X window created will cover its parent, create an
event listener to forward expose events from the child window to
the parent, so that the parent can know to repaint.

BUG= 145600 

Review URL: https://chromiumcodereview.appspot.com/23452026
------------------------------------------------------------------------
If the above patch sticks (fingers crossed!!), then that should get us most of the way to working around this bug.

With these changes, nvidia-smi reports the following memory usage
10 tabs: 192MB -> 107MB (-> 95MB)*
20 tabs: 309MB -> 120MB (-> 103MB)*
30 tabs: 426MB -> 129MB (-> 107MB)*

If I make it so that we share a single "dummy_window" across all GL surfaces, then we can get to the (-> XMB)* numbers. That should be a simple enough patch to land on top of this, and can probably make M31's branch point. I should be able to get rid of the blacklisting in #73 as well.

Also of note is that unity eats up lots of video memory, so switching window managers to (say, to twm) may improve stability somewhat.
Project Member

Comment 143 by bugdroid1@chromium.org, Sep 14 2013

------------------------------------------------------------------------
r223231 | ccameron@chromium.org | 2013-09-14T05:37:58.796784Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/gl/gl_surface_glx.cc?r1=223231&r2=223230&pathrev=223231

Disable child X window workaround when running in test harnesses that do
not have a message loop.

TBR=zmo
BUG= 145600 

Review URL: https://chromiumcodereview.appspot.com/24127004
------------------------------------------------------------------------
This had to be disabled again. Two issues

1. The GPU process is crashing on some bots when starting up the X message loop. This is only affecting bots (no non-bots have been hit by this), so this can be plastered over somehow.

2. When switching out of compositing mode, we do not destroy the child X surface, so it sits in front of the window indefinitely. We can fix this in two ways. One is to make compositing sticky (IMO we should do this anyway). Another is to destroy the child X surface when compositing is disabled. I'm looking to see if the GPU process gets any signals WRT switching compositing -> software, but I haven't seen them yet.
WRT #144

I wrote a patch that informs the GPU process of compositing transitions
https://codereview.chromium.org/23653049
But... when I tested this on complex pages (e.g, gmail when going in/out of compositing mode), I see flashes when the GLX window is destroyed.

I'm going to see about making compositing sticky to a RenderWidgetHostView.
Project Member

Comment 146 by bugdroid1@chromium.org, Sep 24 2013

------------------------------------------------------------------------
r224927 | ccameron@chromium.org | 2013-09-24T06:49:46.329920Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/gl/gl_surface_glx.cc?r1=224927&r2=224926&pathrev=224927

Re-enable child X window workaround.

Compositing has been made sticky for a RenderWidget in the work for
 http://crbug.com/295072 

Now that compositing is sticky, the issue that caused this to be turned
off,  http://crbug.com/292655 , should be fixed.

TBR=piman, kbr
BUG= 145600 

Review URL: https://chromiumcodereview.appspot.com/24224008
------------------------------------------------------------------------
Project Member

Comment 147 by bugdroid1@chromium.org, Sep 27 2013

Labels: -M-31 M-32 MovedFrom-31
Moving all non essential bugs to the next Milestone.
Labels: -M-32 -MovedFrom-31 M-31 Merge-Requested
Requesting merge for M31 for r224927 (all other patches made the cutoff, this has been sitting in TOT for a week without issues).
Labels: -Merge-Requested Merge-Approved
Project Member

Comment 150 by bugdroid1@chromium.org, Sep 30 2013

Labels: -Merge-Approved merge-merged-1650
------------------------------------------------------------------------
r226000 | ccameron@chromium.org | 2013-09-30T17:28:52.502793Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1650/src/ui/gl/gl_surface_glx.cc?r1=226000&r2=225999&pathrev=226000

Merge 224927 "Re-enable child X window workaround."

> Re-enable child X window workaround.
> 
> Compositing has been made sticky for a RenderWidget in the work for
>  http://crbug.com/295072 
> 
> Now that compositing is sticky, the issue that caused this to be turned
> off,  http://crbug.com/292655 , should be fixed.
> 
> TBR=piman, kbr
> BUG= 145600 
> 
> Review URL: https://chromiumcodereview.appspot.com/24224008

TBR=ccameron@chromium.org

Review URL: https://codereview.chromium.org/25311002
------------------------------------------------------------------------
Status: Fixed
This is fixed now, to the extent that it can be. In particular, as of M31:
- We keep around at most 1 GLX window per browser window
- We use a minimal amount of GPU memory to render the page

We'll be switching to Aura on Linux soon (current plan M32), which will keep these two effects (though in a less complicated way).

The root issue (where GPU memory usage can cause the system to hang) is a driver problem, and still exists.

System stability can be greatly improved by switching away from using a composited window manager (and instead using something like gnome-classic).
Right on, thanks Chris!
Cc: -rbyers@chromium.org
Cc: wiltzius@chromium.org
Issue 303898 has been merged into this issue.
Cc: skaslev@chromium.org
 Issue 306479  has been merged into this issue.
Cc: vitalyb...@chromium.org ashej...@chromium.org
Issue 268067 has been merged into this issue.
 Issue 285808  has been merged into this issue.
Can you please tell which beta version all the changes were made in to?

I am running 31.0.1650.39 beta. I am still seeing the issue with only 3 tabs open (although one tab has flash player open) and this is what I see from nvidia-smi -q -d memory:

==============NVSMI LOG==============

Timestamp                           : Sat Nov  2 17:32:53 2013
Driver Version                      : 319.32

Attached GPUs                       : 1
GPU 0000:01:00.0
    Memory Usage
        Total                       : 255 MB
        Used                        : 235 MB
        Free                        : 20 MB


From the chrome task manager, the 3 tabs report GPU memory as:
0K
14,611K
14,610K

If I close chrome completely, the video memory as reported from nvidia-smi goes back to within 50M of use.

I also have compiz running.

Let me know if I need to provide anything else.

 Issue 304386  has been merged into this issue.
Nvidia has updated their Linux/Unix drivers again and it seems they may have fixed the root cause of this issue, can one of the Chromium devs confirm? I've been hitting my Chrome version 32.0.1700.77 and things do get a bit glitchy when 15-20 tabs are open though but it doesn't lock up.

http://www.nvidia.com/Download/driverResults.aspx/72249/en-us

Version:	 331.38
Release Date:	 2014.1.13

"Fixed a bug that caused the X server to crash if video memory is exhausted and the GPU does not support rendering to system memory."

Comment 161 by misch@google.com, Jan 16 2014

I doubt that the change you are quoting is related as current NVIDIA drivers don't crash Xorg when they run out of video memory - they offload to main memory. You can check the video memory usage on Quadro cards by running 'nvidia-smi -q -d memory'. To me the changelog entry reads more like as if this is only an issue with certain GPUs. As there aren't any more details this is certainly an educated guess from my side. ;-)

Anyhow... You can certainly give this driver a try. The NVIDIA 331.38 driver is already available from the X-Edgers PPA: https://launchpad.net/~xorg-edgers/+archive/ppa

Please note that after installing/updating the nvidia-331, nvidia-persistenced and nvidia-settings package you are required to reboot your machine.
Why is this bug still quoted as a problem in chrome://gpu on Chrome/33.0.1750.146 on Linux if it has been fixed?

Comment 163 by tri...@gmail.com, Mar 8 2014

Came here and asking my self the same question as #162

Comment 164 by kos...@gmail.com, Jun 26 2014

It has not been fixed at all. I'm still facing this awful bug. Whenever I load a new page the whole browser freeze. Even the loaded tab can't be seen, it's a blank page instead.

I'm considering using Firefox again under Linux, I'm wasting so much time waiting Chrome "unfreeze" all day long.

Comment 165 by pdr@chromium.org, Jun 26 2014

@koskoz, please make sure you're running the latest version of chrome/chromium (35) and file a separate bug.
@pdr Yes I'm sure about it. But Why open a new bug when it's exactly the same?

Comment 167 by pdr@chromium.org, Jul 1 2014

@antoine, 100 people have starred this bug and are getting updates for every comment. This has been fixed for most of us. If you're still seeing this issue it's likely some other bug with the same symptoms.

I'd be happy to triage any new bugs anyone files, just shoot me an email.
from a common public user: Windows 7 (Dell laptop) - installed, freezes, uninstalled, re-installed, freezes, re-uninstall, re-install again now and still facing same issue. using F11 button, maximize and minimizing every 30 seconds to function. to the extent of sending to IT shop to check what is the problem (cost me USD100 for nothing...)

thread is 2012 and now is 2015...
Labels: Restrict-AddIssueComment-Commit

Comment 170 by kbr@chromium.org, Mar 26 2015

Blocking: chromium:469979
Cc: -vitalyb...@chromium.org

Comment 172 by kbr@chromium.org, Jan 13 2017

Cc: apatrick@chromium.org
 Issue 113686  has been merged into this issue.
Showing comments 73 - 172 of 172 Older

Sign in to add a comment