User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Build Identifier: Firefox 4.0.1 Firefox fills up memory and crashes with an out of memory error (crash dump) after repeated allocation of images in JavaScript even though there are no longer any references to the images that were cached. The garbage collector should be freeing up memory that's no longer used by older cached images rather than running out of memory. Reproducible: Always Steps to Reproduce: 1. Prepare a Windows XP machine with 2 GB memory and NO SWAP FILE (makes it easier to reproduce). 2. Open Firefox 4.0.1 or 5.0 beta 2. 3. Enter the following URL: http://www.clarosa.info/firefox/bug.html This is my stress test program which I developed after seeing this problem on a real websites. Actual Results: The test program enters an infinite loop and continuously caches images until the cache memory fills and the Firefox crashes. The crash dump stack trace shows an out of memory error. It may take several minutes to crash the browser, and I recommend watching memory usage with Task Manager during the test. You can see it fill up and then eventually crash the browser. Expected Results: The program should run continuously without crashing the browser. Firefox 3.6 does not crash when this test script is run. Other browsers (Internet Explorer, Chrome) do not crash either. The script is as follows: for (var j = 0; j < 1000; j++) { for (var i = 1; i < 50; i++) { var image = new Image(); image.src = "test" + i + ".jpg"; } } A new image is created on each loop, however since the previous image no longer has a reference it can be freed up as needed. This appears to not be happening all the time.

Probably has to do with the JS engine not really running GC much in this case because it has no idea that the image data exists....

Would it be possible to teach the GC that the image data exists? This bug was spun off from bug 653970, which is about problems with image-heavy sites.

> Would it be possible to teach the GC that the image data exists? I have no idea... The fundamental problem is that the <img> element will often keep the data alive... but so will some other stuff. We could give GC an overestimate of the data that might be freed by a GC. Would that be ok?

It looks like bug 658604 is related to this bug.

Here's a crash report: Crash Report ID: ed79b265-e3c0-4133-a301-e5ec82110523 Crashing Thread: 0 mozalloc.dll mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:77 1 mozalloc.dll mozalloc_handle_oom memory/mozalloc/mozalloc_oom.cpp:54 2 xul.dll nsTArray_base<nsTArrayDefaultAllocator>::EnsureCapacity obj-firefox/dist/include/nsTArray-inl.h:106 3 xul.dll nsTArray<char,nsTArrayDefaultAllocator>::AppendElements<char> obj-firefox/dist/include/nsTArray.h:770 4 xul.dll mozilla::imagelib::RasterImage::AddSourceData modules/libpr0n/src/RasterImage.cpp:1257 5 xul.dll mozilla::imagelib::RasterImage::WriteToRasterImage modules/libpr0n/src/RasterImage.cpp:2773 It's running out of memory in "mozilla::imagelib::RasterImage::AddSourceData" and it seems like it should be invoking the garbage collector at that point to free up some memory.

I've consolidated a number of bugs about image-heavy sites, including this one, into bug 660577. Please CC yourself on that bug if you want to follow along. Thanks.