672114 - Native resources associated with Canvas are not cleaned up agressively enough

Status: NEW

(Core :: Graphics, defect)

Description

[Clemens Eisserer]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20100101 Firefox/5.0
Build ID: 20110615151330

Steps to reproduce:

We are developing a solution where image-data is streamed from a servlet continously.
Here's a stripped-down version of what we are doing:

function StartImageRequest() {
  var	img = new Image();  
  img.src = 'ImageStreamer?&rand='+randParam; //Some random ID to avoid caching
  img.onload = new function() {
	   var canvas = document.getElementById('canvas');
	   var ctx = canvas.getContext('2d');
	   ctx.drawImage(img, 0, 0);
           StartImageRequest();
  };
}

If there is any interest, I could provide a ready-to-run testcase to demonstrate the problem.

Build identifier: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20100101 Firefox/5.0


Actual results:

When running the script above, the first few hundred iterations work fine, but suddenly FixFox's pixmap memory useage grows without limit - on my system about 50mb/s.
When it reached 500mb, I had to kill FireFox because my system felt choppy and was swapping.


Expected results:

FireFox should somehow restrict the amount of pixmap memory it reserves.

Comment 1

[Thomas Ahlblom]

I don't know much about the details, but quite a lot has happened with the memory management i Firefox recently.

Are you able to verify the issue with the latest nightly?
https://nightly.mozilla.org/


And a testcase would be fine to have, so people can compare different versions of Firefox.

Comment 2

[Clemens Eisserer]

still happens with: Mozilla/5.0 (X11; Linux i686; rv:8.0a1) Gecko/20110717 Firefox/8.0a1

I'll submit a self-containing testcase soon.

Comment 3

[Clemens Eisserer]

Attachment: testcase

Comment 4

[Clemens Eisserer]

The testcase includes a small http server with a servlet, which simply streams down the png image also contained in the archive.

It should be quite simple:
1. unpack the archive
2. change into the "testcase" directory
3. start the sample server: java -jar testcase.jar 
4. open Testcase.html in FireFox

Firefox should after a short time consume quite a lot video memory, on my system the groth-rate is about ~50mb/s.

Comment 5

[Matthias Versen [:Matti]]

graphics or imagelib....

Comment 6

[Boris Zbarsky [:bzbarsky]]

I wonder whether we stop GCing as often after a bit, so all those images are sticking around for a while...

Comment 7

[Clemens Eisserer]

Sorry, my conclusion was wrong - its not image loading, its canvas creation what is causing our problems.

We frequently load images, and need to read the values of a few pixels - therefor we have to create a canvas. However it seems Mozilla's GC doesn't keep track of the native resources consumed by canvas, and because we don't generate a lot of garbage it doesn't clean up agressivly enough:

function torture() {
   while(true) {
    var cmdCanvas = document.createElement('canvas');
	cmdCanvas.setAttribute('width', 100);
	cmdCanvas.setAttribute('height', 100);
	var cmdCtx = cmdCanvas.getContext('2d');
	cmdCtx.fillRect(10, 10, 10, 10);
   }	
}

Comment 8

[Boris Zbarsky [:bzbarsky]]

> its canvas creation what is causing our problems.

Ah, that thought had crossed my mind, but comment 0 was explicitly NOT creating new canvases.

> it seems Mozilla's GC doesn't keep track of the native resources consumed by
> canvas

Except it does, in theory.  See bug 591358 comment 38 (which is a change to do just that).....

That said, to collect a canvas we need to CC too, not just GC.  Is it possible we're not triggering CC anywhere during these repeated canvas creations?

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #7)
> function torture() {
>    while(true) {
>     var cmdCanvas = document.createElement('canvas');
> 	cmdCanvas.setAttribute('width', 100);
> 	cmdCanvas.setAttribute('height', 100);
> 	var cmdCtx = cmdCanvas.getContext('2d');
> 	cmdCtx.fillRect(10, 10, 10, 10);
>    }	
> }
Endless loop sure is bad, even without any gc/cc problems.
Would it be possible to get a testcase which isn't such loop.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

If I change the loop to use setTimeout, gc/cc is called often and
memory usage stays pretty low.

Comment 11

[Clemens Eisserer]

On our real-world application it is basically an endless loop too, polling for a server-response:

function ImageRequest() {
  img = new Image();  
  img.src = "ImageStreamer?rand="+parseInt(Math.random() * 99999999);
  img.onload = handleResponse;
}

function handleResponse() {
  //create a temporary canvas and do some magic
  ImageRequest();
}

So even when running local, there's a lot of other stuff going on (http transfer, image decoding) - it even switches a lot between native and JS code.
The endless loop was just introduced to make the testcase shorter.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

that doesn't look like (synchronous) endless loop, since handleResponse is 
called asynchronously when load event is dispatched.
while(true); is quite different beast.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Yeah, the code in comment 11 should act similarly to what Olli mentioned in cmomment 10...

That said, was comment 10 tested on Firefox 5 or a nightly?  It's possible that the behavior is different now.

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

I was using Nightly. Nightly was used also in comment 2

Comment 15

[Boris Zbarsky [:bzbarsky]]

Hmm, yeah.

The testcase attached in comment 3 doesn't create new canvases, by the way.  Clemens, does that testcase actually show the problem for you?

Comment 16

[Clemens Eisserer]

With the testcase in Comment 3 I can get Firefox to consume 1.6GB of RAM (RES), however the pixmap memory consumption seems to stay steady at ~10mb.

So while FF still behaves bad, its way better than before.