Memory leak drawing canvas on canvas (drawImage)
Reported by
antonioc...@gmail.com,
Jun 30 2016
|
||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 Steps to reproduce the problem: 1. Load Test.html on a usual 2/4GB machine 2. Open console to see results and open Windows Task Manager 3. Click button a select a local file Image (i.e. I use a 4MB image file of 9Mpx) What is the expected behavior? On console, test must finish with no problem showing: Running Memory Leack test: test.html:53 Crash test 200 test.html:53 Crash test 199 test.html:53 Crash test 198 test.html:53 Crash test 197 ... test.html:53 Crash test 1 What went wrong? Memory used by Chrome grows until 100% is reached (you can observe this on Windows Task Manager), then page crashes with the "Oh no, se ha producido un error" (spanish version), and DevTools show the message "DevTools has disconected from page" Crashed report ID: How much crashed? Just one tab Is it a problem with a plugin? No Did this work before? Yes 46.0.2487.0 Chrome version: 51.0.2704.106 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 22.0 r0 I tested with old chromium versions and I found 46.0.2487.0 is the last version test works properly... (https://commondatastorage.googleapis.com/chromium-browser-continuous/index.html?prefix=Win/343863/) This test shows that Canvas memory is not garbaged when drawn on other canvas: Test does: 1.- Loads an Image 2.- Creates a destination canvas 3.- Iterates N times doing 3.1- Creates a temp canvas 4.2- Draws Image on temp canvas 4.3- Draws temp canvas on destination canvas The temp canvas reference is "reassigned" in each iteration. The loop is implemented using a setTimeout to ensure 100ms of wait time between each iteration.
,
Jun 30 2016
Some comments in the test.html file changed
,
Jul 1 2016
,
Jul 4 2016
,
Jul 6 2016
In my opinion, this is the feature of JS. In the test file, a canvas is created in the function inside the setTimeout. Since javascript uses function scope: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/block, a reference to that canvas is retained and not garbage collected. You can use the dev tool to explicitly garbage collect it. By changing times from 200-->20, I saw memory goes to 1.6GB, but when I click GC, the memory goes back to 25MB. I also tested the script on Firefox, and I saw the same behavior.
,
Jul 6 2016
Hi xidac. I added a very simplified test without "timeout". The test works properly on Firefox and Chromium 46.0.2487.0 (20000 loops, memory is garbaged in the middle of the loop automatically), but actual Chrome version crashes "inmediatelly" (tab crashes) depending on computer memory and image resolution). My test is performed with a 3.8Mpx image in a 2GB RAM machine --> Chrome fails before loop 100. Chromium version is located on https://commondatastorage.googleapis.com/chromium-browser-continuous/index.html?prefix=Win/343863/ Later chromium versions fails the test too.
,
Jul 6 2016
in simplifiedTest.html, if you put the "tmpCanvas = document.createElement('canvas');" above the for loop instead of inside it the crash goes away.
This really looks like a regression in the Garbage collection triggers. It is possible that the oilpan heap is trying to wait for an idle period to do GC work, and ends up starving the process.
JavaScript>GC people: any suggestions?
The canvas elements themselves are garbage collected objects, but the underlying pixel buffers are not. They are allocated by skia either using malloc or in GPU memory. Because the buffers are tied to the scope of their respective canvas elements, we use v8::Isolate::GetCurrent()->AdjustAmountOfExternalAllocatedMemory to declare this memory to V8 to create pressure on the GC triggers. It seems this approach is no longer working as well as it used to.
,
Jul 6 2016
Also, related to this, I filed a bug here: crbug.com/626082
,
Jul 13 2016
,
Jul 28 2016
keishi@: could you take a look at #8? Thank you.
,
Jul 28 2016
,
Sep 6 2016
Hello, xidac Blobs have the same problem... (canvas.toBlob(...)): blobs are not freed. Will the https://bugs.chromium.org/p/chromium/issues/detail?id=626082#c29 solution be applied to blobs too?
,
Sep 6 2016
Hi antoniocabreraperez@: could you give a more specific example to demonstrate what is the leak in canvas.toBlob()?
,
Sep 6 2016
Sorry Xidac... I'm trying to reproduce the error with blobs and I can't. I think I was wrong about this.
,
Nov 28 2016
,
Dec 20 2016
,
Apr 6 2017
,
Apr 12 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 19 2018
Closing according to #16 |
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by antonioc...@gmail.com
, Jun 30 2016