Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 145600 Chromium UI freezes on Linux
Starred by 106 users Project Member Reported by jchaffraix@chromium.org, Aug 29 2012 Back to list

Comments by non-members will not trigger notification emails to users who starred this issue.
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.
 
Comment 1 by pdr@chromium.org, Aug 29 2012
I can confirm seeing this but unfortunately can't add any other information :/ I'll respond if I can find out more.
Are other aspects of the browser UI also broken? e.g. can you press the hotdog/wrench menu and get menu as a response?
You can open the wrench menu and get a response. The bookmark bar also reacts and we take the click into account but we don't update the tab strip until you minimize & maximize or close the browser.

If you minimize / maximize, the UI is still frozen but it is updated to match what you were doing: if you opened a new tab, it will show it but you won't be able to switch tabs.
Labels: Feature-TabStrip
I honestly don't have a good answer for you. It sounds like the browser UI process is alive, but the tab strip code is confused somehow.
Comment 5 by Deleted ...@, Aug 30 2012
I am seeing the same problem, but worse. None of the buttons work for upto 20 seconds. And all tabs and windows are affected. I haven't tried maximize / minimize yet, but I bet it does NOT work. Last time I checked, none of the buttons worked, and other windows and tabs of Chromium go completely white with a blue bar at the top when I alt+tab to them. 
Do you have a webcam plugged in? Maybe related to bug 134799?
Comment 7 by kareng@google.com, Sep 5 2012
Labels: Action-BisectNeeded
I think this is a regression Anantha can we have somoen bisect?
Labels: -Type-Bug Type-Regression ReleaseBlock-Stable
@thestig, in my case, no webcam plugged.

It's a pretty severe regression marking as release blocker stable so that it doesn't ship to our users.
Cc: simonjam@chromium.org
In bug 134799, simonjam@ said:

If you're still experiencing slowdowns, can you record a trace of the problem and attach the trace to this bug?

http://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs

Comment 10 by kareng@google.com, Sep 5 2012
Owner: pbomm...@chromium.org
Status: Assigned
Status: Available
--Its the same behavior on all three channels(Stable,Beta and Dev).
--On Current Stable:21.0.1180.89 Beta:22.0.1229.26 Dev:23.0.1255.0 opened 6-10 Tabs and unable to add more tabs and couldn't navigate to other tab, As mentioned in bug report can only access the minimize and Wrench menu options. When first window is freezed tried to open New window and all tabs works fine.
The above behavior was seen on Ubuntu :12.04 Lts/64bit.
@thestig, I haven't seen any CPU spikes when the behavior occurs which makes me suspect a functional bug, not a performance bottleneck.

Anyhow, attached is a tracing done when the issue occurred with the protocol:
* waited 11 seconds after started recording before doing anything.
* at the 11 seconds mark, switched to another tab. We see some GPU activity but the displayed page wasn't refreshed.
* at the 22 seconds mark, switched back to the about:tracing tab. The selected tab didn't even update in the tab strip.
* around 32 seconds, minimized & maximized the window then stopped tracing.
UI-freeze-tracing
6.5 MB Download
Labels: OS-Linux
There's a 2 second texture upload in that trace. That's ridiculous. To me, that indicates something has gone horribly wrong with the GPU.

On the Ubuntu forums, there are lots of complaints about the 295 nvidia drivers that come with Precise. It's likely that's what everyone here are using.

Are you all using the default Unity desktop, which has accelerated compositing? Does it help if you use Unity 2D or another WM? What about if you disable the GPU in Chrome? Maybe we need to blacklist this GPU setup.
Cc: zmo@chromium.org
Labels: -Feature-TabStrip Feature-GPU
FWIW I'm on Precise with the 295.x drivers. Using KDE, I haven't had any issues so far.
I am on Lucid, not sure about the driver version though. Switching "GPU compositing on all pages" to "Disabled" made the issue go away so it's definitely related to the GPU.
The bug description says you're on Precise. Are you seeing the same problem on another machine running Lucid?

You can get the driver version by 'apt-cache search nvidia-current'. There's a Version: line in there somewhere.
err s/search/show/ sorry
>  Are you seeing the same problem on another machine running Lucid?

My apologies, it looks like I forgot to screwed up the Ubuntu version. I am on Lucid and I don't have a Precise machine.

Here is the driver version: Version: 295.71-0ubuntu1~lucid
Well that's the same major version. Maybe we should be blacklisting it. What do you think Mo?
I've seen similar problems on similar driver revs.  I vote blacklist.
Cc: pbomm...@chromium.org pavanv@chromium.org
Labels: -Action-BisectNeeded
Owner: ----
--This was seen on all three Chrome channels(Stable,Beta and Dev. 
--I have updated the results in Comment#11 and Tested on Precise (12.04).
Owner: zmo@chromium.org
Status: Assigned
Sounds like we should blacklist.
Labels: -Type-Regression Type-Bug
--Removing the label regression since it's same behavior with Stable, Beta and Dev channel.
--The Precise(12.04) is an Corp Machine. 
Cc: ccameron@chromium.org
Is this happening only when you have a lot of windows open? Blacklisting these drivers is less than ideal since that means blacklisting all internal users.  I don't know if you gpu memory manager on linux currently makes any attempt to free up front or backbuffers on windows that haven't been visible in a while (like we do on other platforms).  ccameron@ do you know? 
We do make an effort to take away backbuffers from not-visible tabs.  If you have a lot of visible tabs (windows) open, they will all, always, get a GPU memory budget of at least 64MB, and a front and back buffer -- so you can unboundedly stress GPU memory with lots of windows.

If I'm reading it right, the trace shows basically no GPU memory being used (~17MB), which should be far from stressing things.
I think it'd be better to have internal users blacklisted and have a browser that works rather than suffering because of bad drivers.
Comment 28 by zmo@chromium.org, Sep 10 2012
Cc: kbr@chromium.org
Ken, can you let the NVIDIA Linux driver folks know about this and see if they might have an idea of what's wrong?  Hopefully we can get a stabler driver sooner.
Comment 29 by kbr@chromium.org, Sep 11 2012
Cc: enne@chromium.org jam...@chromium.org vangelis@chromium.org nduca@chromium.org
Julien and I reproduced this problem on his gLucid desktop on only a single monitor, and then subsequently I was able to reproduce it on my single-monitor gLucid desktop with a recent beta driver from NVIDIA (304.30) and a Quadro FX 380, running Chrome 23.0.1255.0 (Official Build 154716) dev.

To reproduce, just go to e.g. http://crbug.com/ and Control-click something like 20 bug numbers. Then use Ctrl-Tab to switch between them. At some point the window will start taking something like 2 seconds to update. Behavior where the window visibly redraws from top-to-bottom can also be observed.

I've seen similar behavior on this card with GPU-intensive content like MapsGL. See Issue 139861. I think that Chrome is allocating a large amount of VRAM, and the driver is doing a bad job paging textures on and off the card.

It would be really good if the new GPU memory statistics could be used to confirm this hypothesis, but currently it's reporting that one renderer process is using 14,402K, the GPU process is using (14,402K), and the rest of the processes are using either 0K or N/A.

I'll point out this issue to NVIDIA, but in the meantime we need to see how much VRAM we are using and whether reducing VRAM consumption will address the problem.

Comment 30 by kbr@chromium.org, Sep 11 2012
FWIW, I think this problem is probably most severe on older hardware like the Quadro FX 380, so we might consider blacklisting compositing -- or at least compositing on all web pages -- on this device, rather than the entire driver family. This is still a poor option though since the problem is only exacerbated by the recent turning on of GPU acceleration for all web pages by default. I think that getting a handle on VRAM consumption in the compositor will improve the behavior to the point that this measure will not be necessary.

Comment 31 by kbr@chromium.org, Sep 11 2012
Note: ccameron@ indicated that the GPU memory accounting is probably correct. The GPU process's number is the sum of the size of all tabs' resources; and the number for the renderer process is the amount of texture memory that one has allocated. The background tabs' resources have been flushed, which is why they report 0K VRAM usage.

This is pretty poor behavior. The indication is that if we ever get an OpenGL context into this horrible paging state that it stays in that state forever, regardless of how much VRAM is subsequently released.

Comment 32 by kbr@chromium.org, Sep 11 2012
Cc: backer@chromium.org
ccameron@ suggested changing the GPU memory management policy to hold on to the resources rather than discarding them for backgrounded tabs. In this mode the browser eventually still got into the state where switching tabs was extremely slow.

It looks like once one tab is affected, it stays slow, even if other tabs are closed. This is again similar behavior to that in Issue 139861. It's possible that forcibly destroying the OpenGL contexts associated with backgrounded tabs' compositors would work around this problem.

We noticed that if GPU compositing for all web pages is forced on and one tabs through ~20 composited tabs, the browser process's private memory size skyrockets. It looks like there is a severe memory leak. This doesn't happen on Mac OS X, for example. Filing this separately, since it's not clear whether this might be the real reason this behavior is happening on Linux.

Comment 33 by kbr@chromium.org, Sep 11 2012
FYI, here's Chris's patch which disables the releasing of background tabs' GPU resources.

memory-manager.diff
2.2 KB View Download
Comment 34 by kbr@chromium.org, Sep 11 2012
Blockedon: chromium:147737
Issue 147737 filed about the browser process memory leak. Blocking this bug on the other because it's pointless to investigate this further with this known memory leak present.

Comment 35 by kbr@chromium.org, Sep 11 2012
Severe performance degradation filed as NVIDIA Incident Report 1047408.

I think the only potential workaround for this issue would be to destroy the compositor's OpenGL contexts on background tabs. Clearly, just destroying the textures isn't sufficient, and it looks like the slowdown is persistent for a given tab, and doesn't necessarily occur for newly created tabs.

Comment 36 by kareng@google.com, Sep 11 2012
Labels: Mstone-23
Comment 37 by kbr@chromium.org, Sep 11 2012
Cc: piman@chromium.org
Attached is a GPU trace when the pathologically slow repaints are occurring. Note that each call to swap buffers is taking ~4 seconds.

In this situation the command line argument --disable-in-browser-thumbnailing was used to work around the resource leak in Issue 147737 . The GPU process still grew to ~400 MB private page usage, though only ~12 MB GPU memory was used at any particular point.

Comment 38 by kbr@chromium.org, Sep 11 2012
slow_swap_buffers.trace.gz
1.0 MB Download
Comment 39 by kbr@chromium.org, Sep 12 2012
ccameron and I spent more time today investigating this issue. We used the GL_NVX_gpu_memory_info extension to log the current available video memory over time and confirmed that the pathologically slow behavior begins when the available VRAM gets very low. When a tab gets into this state, it doesn't recover until its OpenGL context is re-created. (For example, navigations within the same domain, which re-use the renderer process and consequently the compositor instance, exhibit the same behavior.)

Chris wrote a test (attached) which allocates a certain amount of texture memory using WebGL. This test case also provokes the behavior usually only by creating a second, new, tab, and toggling between that one and the test case. Occasionally it's necessary to open one or two more composited tabs to get the machine into the bad state.

We found that composited tabs consumed a considerable amount of video memory (~10 MB each) even when backgrounded, presumably because each one renders into its own X window which has an associated (double-buffered) OpenGL context. Chris hypothesized that resizing backgrounded tabs' surfaces to 1x1 might reclaim video memory; unfortunately, it doesn't. Interestingly, glDeleteTextures calls also don't reclaim VRAM, not even if followed by a glFinish. It looks like the driver holds on to the allocated VRAM just in case the application will use it again. Closing backgrounded tabs did reclaim the VRAM. At one point we found that closing one tab resulted in the release of ~40 MB of VRAM!

Based on these experiments it looks like some solutions that will actually reduce VRAM consumption to an acceptable level would be:

1) Forcibly lose background tabs' OpenGL contexts. Alternatively, lose all but the N most recently used backgrounded tabs' contexts.

2) Virtualize Chrome's OpenGL context management to be able to use one context to render multiple composited tabs to the screen. This will be very difficult in particular on X11, where it would almost certainly be necessary to maintain two OpenGL contexts, one for rendering into a window and one for all other offscreen rendering. The reason for this is that the GLXFBConfig requirements may be different for those two situations.

3) Change the RenderWidgetHostViewGtk architecture to use one on-screen window for multiple tabs. This might be a more feasible intermediate step than (2).

Note that (1) will not conclusively solve this problem; applications allocating many large composited layers, or WebGL applications allocating large amounts of textures, would be able to get into the same state with only one tab visible.

I'll add this information to NVIDIA incident 1047408 along with the test case.

Note also that this problem appears to mostly affect old graphics cards such as the Quadro FX 380.

test-b.html
4.3 KB View Download
Could we get the renderer to pro-actively destroy its GL context when backgrounded to avoid doing it forcibly via a Lost Context as proposed in (1)?  

The introduction of Aura will help a lot here.  It will essentially do (3) for us.  
Comment 41 by nduca@chromium.org, Sep 12 2012
@ccameron, @kbr, did the synthesizing a lost-context run into an issue after we chatted earlier?
We haven't tried forcing a lost context yet -- sorry, we got side-tracked when we found that we could trigger the behavior with just 1 context.

I'd prefer to avoid doing lost-contexts except as a short-term measure because it will cause very bad tab-switch behavior (not only do we need to re-upload everything, we need to recreate the GL context first).

The memory manager work is aiming to be able bring backgrounded tabs down to its minimal memory footprint where they still can be drawn when they're switched to without any new uploads (and ideally without even going back to the main thread).

I'd prefer to have a single swap-chain per window, instead of having one per-tab (or even having that capability).  The minimal fast-tab-switch footprint is ~1 screen of tiles, and keeping around a swap-chain per tab takes another ~1 screen worth of data (~2 if it's double-buffered).  Therefore, keeping around a swap-chain per-tab means cutting the number of warm tabs that we can have by a factor of 2 or 3.  I'm going to try to add swap-chain/front-buffer reporting to the task manager.

I think that (2) -- context virtualization -- will result in an overall performance and stability improvement.  Many  (most? all?) graphics drivers make local (per-context) decisions that end up with sub-optimal multi-context behavior.  For example, a driver may decide to defer freeing the resources that we delete in one tab (just in case we need to use them again), and the driver won't re-evaluate that choice until the tab is active again (so the resources will hang around while another tab wants them).

I was forwarded to this bug because I am encountering this issue and have posted some traces.  My comments start at http://code.google.com/p/chromium/issues/detail?id=134799#c61 and I have performed some traces and hopefully you will find something of use for them.  Same behavior on a Nvidia 8400M GS version 304.43.  If you need any information from me just ask...thank you...
Those traces look nearly identical to issue 141377, and should hopefully be fixed in 22.
@ccame(...) what is the specific revision number?  Will this be available in the Linux x86_64 Chrome "Unstable" channel so when I get to my Linux system or is in BETA?
Owner: ccameron@chromium.org
@nduca, I put something together that has the GPU memmgr trigger a context lost -- its parts are at
https://bugs.webkit.org/show_bug.cgi?id=96585
https://codereview.chromium.org/10913240/

Ken and I will check it out on one of the afflicted machines tomorrow.

Comment 48 by kbr@chromium.org, Sep 14 2012
Attached is Chris's patch modified for the downstreaming of the cc/ classes.

It definitely constrains the use of VRAM. However, there's one significant bug, which is that it isn't properly recreating the context when the tabs are brought to the foreground. That means that tabs for which the context was forcibly lost are never properly updated, making it difficult to evaluate how well this patch will work in practice since there's no real context churn.

Also, it's necessary to use the command line --disable-in-browser-thumbnailing in order to work around some errors which would be necessary to fix in a productized version of this patch.

force-lost-context.patch
10.4 KB View Download
Comment 49 by kbr@chromium.org, Sep 14 2012
Chris pointed out that --enable-threaded-compositing is needed too, and that works. Seeing some strange results regarding VRAM consumption; investigating with Chris.

Comment 50 by kbr@chromium.org, Sep 14 2012
The strange behavior Chris and I were seeing was that the VRAM consumption wasn't going down when OpenGL contexts were being destroyed.

After doing more investigation and adding more logging, it strongly looks like Chromium is leaking permanent XIDs created for composited tabs in some situations, specifically when the backgrounded tab doesn't have an OpenGL context. (But, thinking about this more, that behavior is newly introduced with this patch...would have to test with a vanilla TOT build just with the additional VRAM and XID logging added to confirm)

Here's the current patch and the logging output from a run with a trivial .html file, with compositing mode forced on and the threaded compositor enabled. 8 copies of the .html file were opened, cycled through, and then shut down in least recently used order. Note that the calls to GetPermanentXIDForId / ReleasePermanentXID are unbalanced.

log.txt
9.6 KB View Download
test.html
44 bytes View Download
current.patch
13.0 KB View Download
Labels: Hotlist-GoogleApps
FYI, I have a problem that appears to be similar, but does not lead to Chrome UI freezes. It rather slows down the entire system to a crawl, with simple operations such as program switching taking noticeable time.

It seems to be related to VRAM, every time I experience the slow down my GPU memory (as reported by `nvidia-smi --query --display=memory` is nearly exhausted.

It appears to get better after disabling compositing, but the problem does not disappear entirely - after several hours of Chrome use with compositing disabled and many tabs open, I still get the same memory exhaustion.
Even with the attached patch, if you switch tabs rapidly, because of the raciness of the GPU memory manager's communication with the renderer processes, you will end up creating more than the limited number of contexts (with the limit set to 8, I've created 16 concurrently).  IMO, killing the actua GL context should be done in the GPU process, soas to effect a hard limit.
Comment 54 by kbr@chromium.org, Sep 17 2012
With the logging in GtkNativeViewManager still in place but the part of the patch which forces lost context for hibernated tabs disabled, the leak of permanent XIDs looks like it goes away. (A couple are lost, but for the 9-tab situation, 8 permanent XIDs are released.) I think that if the patch were modified to lose the compositing surface for hibernated tabs and re-create it on demand that the VRAM consumption would decrease for this scenario.

This hasn't gotten any attention lately -- both Ken and I have been on other issues.
Got another freeze this time on a random Citrix "Xen Desktop" virtual Linux appliance installed recently in a field trial at the University that I attend.  It froze the entire machine when I had several Google Plus, Calendar and Gmail pages open requiring a reboot so I believe that it was related to #145600 because of the total X11 lockup.  The version - and I should have gotten more detailed info but was on the run - was series 19.x.xxxx.xx.  The really urgent point here is that the Linux appliance only had a single application and that was Chrome.  If the University Administrators had observed this lockup they would cancel the field trial and reject the Citrix product thus causing the Citrix vendor to lose a potential contract with a large institution. Yes I know that Chrome OS would probably be a much better product for that particular use case. But #145600 is a major liability in a commercial/corporate large scale situation and makes Chrome deployments risky. 
It looks like this is limited to Tesla-generation chips.  The marketing names for these things is:
    Geforce 8xxx and 9xxx
    Geforce GT/GTX/GTS/etc 2xx and 3xx
I haven't seen any reports of this happening on Fermi or Kepler-generation chips.  The marketing names for those chips is
    Geforce GT/GTX/GTX/etc 4xx and 5xx (Fermi) and 6xx (Kepler).

Has anyone seen this lockup on any of the more recent chips?

If no, then the best scheme may be to just blacklist Tesla generation until the driver bug is fixed.
It doesn't happen at home for me though, yet:

OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTS 250/PCIe/SSE2
OpenGL version string: 3.3.0 NVIDIA 295.49

(That's on stock Ubuntu 12.04, no compositing WM).


It does happen on my old work desktop:

OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: Quadro FX 380/PCIe/SSE2
OpenGL version string: 3.3.0 NVIDIA 295.71
(Goobuntu Precise, no compositing WM)


But not on my new one:
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: Quadro 600/PCIe/SSE2
OpenGL version string: 4.2.0 NVIDIA 295.40
(Goobuntu Precise, no compositing WM)


So I think there's more than the chip generation involved.
Here is the XenDesktop 4.1 Linux Appliance version information hope it helps:

--------------------------------------------
about:version
--------------------------------------------

Google Chrome	19.0.1084.56 (Official Build 140965)
OS	Linux
WebKit	536.5 (@119244)
JavaScript	V8 3.9.24.29
Flash	11.2 r202
User Agent	Mozilla/5.0 (X11; Linux i686) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5
Command Line	 /usr/bin/google-chrome --proxy-auto-detect --flag-switches-begin --flag-switches-end
Executable Path	/opt/google/chrome/google-chrome
Profile Path	/home/nxtop/.config/google-chrome.default/Default


--------------------------------------------
about:gpu
--------------------------------------------
Graphics Feature Status
Canvas: Software only, hardware acceleration unavailable
Compositing: Hardware accelerated
3D CSS: Hardware accelerated
CSS Animation: Accelerated
WebGL: Hardware accelerated
WebGL multisampling: Hardware accelerated
Problems Detected
Accelerated 2d canvas is unstable in Linux at the moment.
Version Information
Data exported	Mon Oct 01 2012 15:36:29 GMT-0400 (EDT)
Chrome version	19.0.1084.56 (Official Build 140965)
Operating system	Linux 2.6.35-22-generic-pae
Software rendering list version	1.29
ANGLE revision	1022
2D graphics backend	Skia
Driver Information
Initialization time	63
Vendor Id	0x0000
Device Id	0x0000
Optimus	false
AMD switchable	false
Driver vendor	
Driver version	
Driver date	
Pixel shader version	
Vertex shader version	
GL version	1.4
GL_VENDOR	Tungsten Graphics, Inc
GL_RENDERER	Mesa DRI Intel(R) Sandybridge Desktop
GL_VERSION	1.4 (3.0 Mesa 8.0.2)
GL_EXTENSIONS	GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_program GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_copy_texture GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_object GL_EXT_multi_draw_arrays GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array GL_3DFX_texture_compression_FXT1 GL_APPLE_packed_pixels GL_ATI_draw_buffers GL_ATI_texture_env_combine3 GL_ATIX_texture_env_combine3 GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_NV_blend_square GL_NV_depth_clamp GL_NV_light_max_exponent GL_NV_texgen_reflection GL_NV_texture_env_combine4 GL_NV_texture_rectangle GL_NV_vertex_program GL_NV_vertex_program1_1 GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SUN_multi_draw_arrays
Comment 60 by kareng@google.com, Oct 4 2012
Labels: -ReleaseBlock-Stable
removing this as blocker since it's not new to m23 and also no safe/simple/easy fix at the moment.
Comment 61 by jut...@gmail.com, Oct 4 2012
OS: Ubuntu 12.04
Chrome Version: 21.0.1180.79

Hi all, I think I fixed the problem by doing the following:
Applications->System Tools->Preferences->CompizConfig Settings Manager->disable the Application Switcher->tick Static Application Switcher

Hope it helps!
KarenG, wanted to confirm that this happened again on both my home Ubuntu 12.04 (XFCE) Nvidia 8400M GS machine and the Xen Desktop Linux Intel Sandybridge appliance unit and all I was doing was browsing normal pages such as Google Plus and Youtube.  Please, can you give me a timeline on this?  It's making Chrome unusable.  
@piman, comment #58:
It looks like the cards that are having trouble are (1) Tesla generation and (2) small-FB -- in particular, ~256MB.

The only thing that can get into M23 at this point is more aggressive GPU blacklisting.  Perhaps we should blacklist NV cards that have <=256MB of VRAM?  I'd also like to restrict the blacklist to Tesla-generation, but I don't see a good way to determine the chip generation in OpenGL (and there are probably very few Fermi+ generation chips with <=256MB VRAM).
I have an Nvidia Quadro FX 580 with 512MB of VRAM and am experiencing this issue on Ubuntu 12.04.

I believe the FX 580 is Tesla generation, so that still makes sense.
@#63 Fair enough, the GPU that break has 256MB, the ones that don't have 1GB.
Comment 66 by levin@google.com, Oct 5 2012
I think I was hitting this. I mention it because I have a 1gb card.

GL version	4.2
GL_VENDOR	NVIDIA Corporation
GL_RENDERER	Quadro 600/PCIe/SSE2
GL_VERSION	4.2.0 NVIDIA 295.40

Precise with unity (but I was told that perhaps mdm@ was doing some changes that may have caused something related to this. I turned off compositing so I'll see if I get a repro again or not.)


I managed to hit this on a Quadro 600 with 1GB as well.

For M23, we're going to blacklist NVIDIA GPUs, with the exception of WebGL and 3D CSS (we will stay blacklisted for Flapper and video).

For M24, we're going to add more complicated workarounds to try to limit the number of contexts that we create.
Comment 68 by misch@google.com, Oct 5 2012
Is this something NVIDIA can and will address in future driver versions?
If so please tell them that it would be highly desired that they also include this fix in the v295 driver series and not only in the v304 series.
In the meantime to blacklist the problematic GPU features momentarily I just use the following command line: 'google-chrome --blacklist-accelerated-compositing'? 
The flag "--disable-accelerated-compositing" should do it.
Comment 71 by karen@chromium.org, Oct 10 2012
Labels: -Mstone-23 MovedFrom-23 Mstone-24
Moving all non essential bugs to the next Milestone
We'd like to add an extra blacklist entry to this one for M24-stable, to improve stability.
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
Sign in to add a comment