Setting Canvas Properties Slows Tab Close
Reported by
jsweeney...@gmail.com,
Nov 6 2016
|
||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.87 Safari/537.36
Steps to reproduce the problem:
1. Enter the following code into a webpage or the Javascript console:
var canvas = document.createElement('canvas')
document.body.appendChild(canvas)
var i = 0
var timeout = setInterval(function() {
if(i > 3000) {
alert("now close the tab")
clearInterval(timeout)
}
i++
var context = canvas.getContext('2d')
canvas.width = 500
canvas.height = 500
//Here's the magic:
canvas.width *= 2
canvas.height *= 2
context.scale(2, 2)
}, 0)
2. Close the tab
What is the expected behavior?
The tab will close immediately
What went wrong?
The tab hangs for a brief period before closing.
It might be possible to cause Chrome to crash, but I wasn't able to consistently reproduce this behavior in isolation.
Did this work before? N/A
Chrome version: 54.0.2840.87 Channel: stable
OS Version: OS X 10.11.6
Flash Version: Shockwave Flash 23.0 r0
If a canvas width/height is modified with "*=" and context.scale() is called over multiple intervals, closing a tab will briefly freeze the browser.
,
Nov 7 2016
,
Nov 8 2016
Unable to reproduce the issue on Windows-7, Mac-10.11.6 and Linux Ubuntu-14.04 using chrome stable version 54.0.2840.87 and Latest canary 56.0.2913.0 . Please find the attached screen-cast and could you please, let us know if anything missed here to reproduce the issue. Thanks.
,
Nov 8 2016
Perhaps it's hardware related? I'm on a early 2013 Macbook Pro. Here's the system report: Hardware Overview: Model Name: MacBook Pro Model Identifier: MacBookPro11,1 Processor Name: Intel Core i5 Processor Speed: 2.6 GHz Number of Processors: 1 Total Number of Cores: 2 L2 Cache (per Core): 256 KB L3 Cache: 3 MB Memory: 8 GB Boot ROM Version: MBP111.0138.B17 SMC Version (system): 2.16f68 Serial Number (system): C02LP0YCFH04 Hardware UUID: F89B670A-78E2-59B0-BEF6-A7DB66F3FF43 I also was able to reproduce after disabling extensions, so those can be ruled out.
,
Nov 8 2016
I can repro on my mac book pro with Chrome 54. Did not repro in 53.
,
Nov 15 2016
Tested the issue on MacBook Pro (Retina,15-inch,Mid 2014) using chrome stable version 54.0.2840.98 and latest canary 56.0.2919.0 and reported version 54.0.2840.87. Able to reproduce the issue.But I was unable to reproduce it consistently. Thanks..
,
Nov 18 2016
Locally I can repro this bug consistently. I did a bisect, and I got this changelog: https://chromium.googlesource.com/chromium/src/+log/65f01f1e64e676b379f42fcaa2fc25f3c6295dfe..fb0fd2cfd895efb50f6645f2177d9bf0639451d6 I tried reverting this locally: Reenable IOSurfaces for Canvas on Mac. by erikchen and things are working fine. erikchen@: could you take a look?
,
Nov 18 2016
For people who can reproduce this issue, can you take a trace using chrome://tracing? https://www.chromium.org/developers/how-tos/submitting-a-performance-bug
,
Nov 19 2016
In the bad case: We make create GMBs 3000 times [presumably caused by resize]. Not sure if this is directly related. In the bad case, the renderer requires does a lot of work before it closes [v8 compile, v8 gc, etc.]. In the good case, the renderer does almost nothing.
,
Nov 21 2016
Observation: traces show that "nothing" is happening during the hang. This is because tracing does not capture events that start as NSEvents and get routed directly to elements in the responder chain. When I press Cmd-W, I get a beachball for ~1s, and during that time, the menu item for "File" remained highlighted. From investigation into Issue 651203, we know that this means that Chrome is actually stuck in a nested CFRunLoop running in an AppKit private mode. For some reason, this is taking more than 100ms to return. Very concerning!
,
Nov 22 2016
I thought that maybe Chrome is overloading the GPU. So I waited for a minute and then closed the tab. Same issue! So Chrome is triggering something during tab close that's causing this behavior.
,
Nov 23 2016
I wanted to see if the stall correlates with the number of times the canvas is resized. So I modified the script to different numbers of resizes. There appears to be a strong correlation - more resizes = longer stall. Then I Tried 3 * 10^5 resizes. My entire system ran out of memory and pretty much died. Huh! So then I tried running the page with Activity Monitor open. System physical memory usage increases by about 1GB / 3-4 seconds. But process memory usage doesn't increase. This implies that Chrome is somehow causing the kernel to use massive amounts of memory.
,
Nov 23 2016
I modified the script to resize the canvas very infrequently. Kernel memory usage grows very slowly. Navigating away from the page clears the memory. Waiting around does not. This suggests that we are improperly managing some memory. [probably IOSurfaces?]. Seems like a serious bug.
,
Nov 23 2016
Changing the logic in Canvas2DLayerBridge::mailboxReleased to set contextLost = false fixes the problem. The problem is that we're not freeing the resources for the chromium image on destruction of the context.
,
Nov 23 2016
,
Nov 28 2016
We should track this type of memory allocation in the future with Memory-Infra tracing, which will allow leaks to be detected by CI testing. See https://bugs.chromium.org/p/chromium/issues/detail?id=669104
,
Nov 29 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5b30ac6ab9aec356b4a4057b5f934feac9821a7f commit 5b30ac6ab9aec356b4a4057b5f934feac9821a7f Author: erikchen <erikchen@chromium.org> Date: Tue Nov 29 19:13:04 2016 Fix Canvas2DLayerBridge IOSurface leak. The IOSurface wasn't being released when the Canvas2DLayerBridge was destroyed before the texture was returned. BUG= 662696 Review-Url: https://codereview.chromium.org/2537003002 Cr-Commit-Position: refs/heads/master@{#435050} [modify] https://crrev.com/5b30ac6ab9aec356b4a4057b5f934feac9821a7f/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.cpp [modify] https://crrev.com/5b30ac6ab9aec356b4a4057b5f934feac9821a7f/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridgeTest.cpp
,
Nov 29 2016
,
Nov 29 2016
This seems moderately serious. Should we should merge to 56 at a minimum?
,
Nov 30 2016
Awesome work Erik tracking this down!
,
Nov 30 2016
,
Nov 30 2016
Your change meets the bar and is auto-approved for M56 (branch: 2924)
,
Dec 1 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/73b8de7c855c922dcbdd5b37919897399c01b984 commit 73b8de7c855c922dcbdd5b37919897399c01b984 Author: Erik Chen <erikchen@chromium.org> Date: Thu Dec 01 21:15:28 2016 [Merge to 2924] Fix Canvas2DLayerBridge IOSurface leak. > The IOSurface wasn't being released when the Canvas2DLayerBridge was destroyed > before the texture was returned. > > BUG= 662696 > > Review-Url: https://codereview.chromium.org/2537003002 > Cr-Commit-Position: refs/heads/master@{#435050} > (cherry picked from commit 5b30ac6ab9aec356b4a4057b5f934feac9821a7f) Review URL: https://codereview.chromium.org/2542033003 . Cr-Commit-Position: refs/branch-heads/2924@{#264} Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059} [modify] https://crrev.com/73b8de7c855c922dcbdd5b37919897399c01b984/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.cpp [modify] https://crrev.com/73b8de7c855c922dcbdd5b37919897399c01b984/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridgeTest.cpp
,
Dec 2 2016
Verified the issue on Mac 10.12 & 10.11.6 using chrome latest Dev M56-56.0.2924.14 by following steps mentioned in the original comment. Observed that tab closed immediately.Please find the screen cast for reference.Hence adding TE-Verified label. Thank you! |
||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||
Comment 1 by kochi@chromium.org
, Nov 7 2016