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

Issue 160411 link

Starred by 7 users

Issue metadata

Status: Fixed
Closed: Nov 2012
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Sign in to add a comment

GPU Accelerated Canvas Memory Leak leads to Crash

Reported by, Nov 10 2012

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11

Steps to reproduce the problem:

What is the expected behavior?
The browser uses a fixed amount of memory

What went wrong?
Two chrome.exe processes consume a continually increasing amount of memory.  I narrowed it down to the process hosting the tab and the GPU process.  Killing the tab's process causes the GPU process to free its extra memory as well.  Setting "Disable accelerated 2D canvas" on "chrome://flags/" fixes the issue.

Crashed report ID: 

How much crashed? Just one tab

Is it a problem with a plugin? No 

Did this work before? N/A 

Chrome version: 23.0.1271.64  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)

Comment 1 by, Nov 14 2012

 Issue 160651  may be a slightly different manifestation of the same underlying problem.
Labels: Internals-Graphics Feature-GPU-Canvas2D

Comment 3 by, Nov 15 2012

Looks like this was fixed recently.
Memory consumption is stable in chrome 25.0.1326.0 canary
Memory leak is present in Chrome 24.0.1312.5 beta-m

karen & dharani:  Do we need this fixed in 23 or 24?
I have no idea what fixed this, but it is fixed in trunk.
junov: could you please tell from which M25 build fixed this? May be we could look at regression window to get it merged in M23/M24.

Comment 5 by, Nov 16 2012

I am able to reproduce on Chrome Version 25.0.1326.0 canary
170 KB View Download
Status: Untriaged
Tested this issue on Windows7 & 25.0.1326.0 (Official Build 167880) canary. Memory leakage is below 100MB and haven't seen Crash.

Able to repro crash in 23.0.1271.64 version. 


Comment 8 by, Nov 16 2012

Hmmm.. I am observing the leak in canary today...  Not sure if I tested it right yesterday. 

The leak seems unrelated to other features that have an incidence on accelerated 2d canvas (threaded compositing, defered canvas).

Also I verified that the the is not a garbage collection related leak.

jqplot looks like it is using persistent canvas objects that are stored in a manger and get re-cycled at each re-draw.  So this is a GC-friendly implementation.

Something interesting that happens here is that the inspector shows canvases being rapidly added and removed from the DOM tree continuously.  I wonder if this could be triggering the leak. 

Interestingly enough the GPU memory (as reported in the task manager) doesn't seem to be growing. The mac also suffers from the same issue although the mem growth rate seems a lot slower.

I did verify that disabling accelerated 2d canvas makes the problem go away.

This is severely impacting a production application of ours making it unusable for the bulk of our users; it seems to be caused when drawing in-memory canvii and then compositing them onto a rendered canvas.

Is there some hack or other to disable GPU canvas rendering on a per-page basis? (for instane, I seem to recall for a while to make it accelerated was to apply a CSS 3D transformation to it) I'm afraid the answer is likely to be no, but worth a shot.

Comment 11 by, Nov 22 2012

To comment 10#:
The CSS 3D transforms have no impact on 2D canvas acceleration. There is a hack: currently, canvases 256x256 or smaller are not accelerated, but that undocumented behavior is far from being set in stone, so don't rely on it long term.

When you say "compositing", do you mean by calling drawImage, or do you mean superposing the canvas elements by inserting the canvas into the DOM?

The test case in seems to be adding and removing the canvas from the DOM repeatedly, which might be the point of failure (pending more investigation). Can you confirm whether you application is also doing that?  If you could attach an additional test html file (or a jsfiddle) that reflects what your application is doing, that could be helpful.

To comment #11:

Okay, makes sense. Sadly, making the canvas 256x256 is not possible; it's a full-screen application and there's no way we could shoehorn it into an area of that size even temporarily.

When I say compositing, it's drawing one canvas onto another (via drawImage), in order to use globalCompositeOperation on a subset of the items. The site in question is – there's quite a lot going on there, and it took me forever to track the problem down as being this (for the longest time I was betting the memory leak was on our side), so I'm not sure of the usefulness of using that as a test-case (and we'll likely be trying to deploy a workaround as soon as we can)

I'll try and cook up a minimal test-case.
…also to comment #11:

Also, regarding adding/removing canvii to the DOM, no our application does not do that. There is a cached canvas object which is used for all of the compositing operations (which will always be in a detached state from the actual DOM)
Note:  this is probably different from  issue 160651 , since VRAM is not growing in this case, only system memory in the GPU and renderer processes.
Bisecting manually points at  However, note that syncing before that change only eliminates the system memory leak in the GPU process. The renderer process is still leaking.
It definitely seems to be caused by the group markers enabled in  If I comment out this line:

--- a/Source/WebCore/platform/graphics/skia/ImageBufferSkia.cpp
+++ b/Source/WebCore/platform/graphics/skia/ImageBufferSkia.cpp
@@ -79,7 +79,6 @@ static SkCanvas* createAcceleratedCanvas(const IntSize& size, ImageBufferData* d
     GrContext* gr = context3D->grContext();
     if (!gr)
         return 0;
-    context3D->getExtensions()->pushGroupMarkerEXT("AcceleratedCanvasContext");

both leaks go away.  I'll try moving the group marker push to SharedGraphicsContext3D creation.
Labels: WebKit-ID-103082
Upstreamed as
Project Member

Comment 19 by, Nov 22 2012

Labels: -WebKit-ID-103082 WebKit-ID-103082-NEW
Summary: GPU Accelerated Canvas Memory Leak leads to Crash
Project Member

Comment 20 by, Nov 22 2012

Labels: -WebKit-ID-103082-NEW WebKit-ID-103082-ASSIGNED

Comment 21 Deleted

Project Member

Comment 22 by, Nov 27 2012

Labels: -WebKit-ID-103082-ASSIGNED WebKit-ID-103082-RESOLVED WebKit-Rev-135809
Status: Assigned
Labels: Merge-Requested Mstone-24
The above WebKit fix rolled into Chrome as of r169743, and is shipping in Canary.

I'd like to merge this down to M24, since the fix is low-risk and it's a pretty bad regression.

Comment 25 by, Nov 28 2012

Labels: -Merge-Requested Merge-Approved

Comment 26 by, Nov 28 2012

Labels: -Merge-Approved Merge-Merged-1312
Status: Fixed

Comment 27 by Deleted ...@, Dec 8 2012

I'm experiencing this issue on Windows 7 with Version 23.0.1271.95 m.

After disabling gpu acceleration for the 2d canvas the leak disappeared.

Project Member

Comment 28 by, Mar 10 2013

Labels: -Internals-Graphics -Feature-GPU-Canvas2D -Mstone-24 Cr-Internals-Graphics Cr-Internals-GPU-Canvas2D M-24

Comment 29 by Deleted ...@, Aug 22 2014

This exact same issue is still happening to me with Win7 and chrome
Version 36.0.1985.143 m, Version 39.0.2130.0 canary.

When i tried with Chrome 25.0.1364.152 it was fixed.

Comment 30 by, Aug 28 2014

Not fixed, this is an regression
#29 and #30, Are you seeing this with the fiddle from the original post? Does disabling accelerated canvas fix the issue for you?
The original fiddle does not reproduce the issue for me in Version 41.0.2272.118 m
Components: -Internals>Graphics Internals>GPU
Moving old issues out of Internal>Graphics to delete this obsolete component (  for details)

Sign in to add a comment