653970 - Unreasonable memory usage on image heavy site

Status: RESOLVED DUPLICATE of bug 660577

(Firefox :: General, defect)

Description

[byzod]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

For general browsing
1. With the image downloading, memory usage increasing to extremely high, to crash
2. Memory won't "smart" release (to prevent crash)

For saved pages browsing
1. Awful memory usage on load, very possibly makes crash
2. Memory still increasing while browsing

Reproducible: Always

Steps to Reproduce:
In the following statements,
*RAM usage = Physical RAM usage, refers to the green bar in your Task Manager (taskmgr.exe)
*VRAM usage = RAM + Virtual RAM usage, refers to the "Commit(MB) xx/xxx" in the bottom of your Task Manager, which indicates the actually memory all the program is using (including firefox of course)

>>>For general browsing<<<
1. Open http://www.gcforum.org/viewthread.php?tid=5721
2. Waiting for the download complete (may takes a long time), press win+r, type "taskmgr" in, after the task manager started, switch to the Performance tab.
3. Start browsing, scroll down the whole page.



<<<For saved page>>>
1. Open http://www.gcforum.org/viewthread.php?tid=5721, save it as xxx.htm+xxx_files (should be around 68MB in total).
2. Press win+r, type "taskmgr" in, after the task manager started, switch to the Performance tab.
3. Drag the htm file into your browser, watch the RAM and VRAM usage.
4. When the RAM & VRAM stop changing, start browsing, scroll down the whole page.

Actual Results:  
>>>For general browsing<<<
In the step 2, the RAM usage should increase slowly, eventually it ate me 1.3 GB ram space.
In the step 3, the VRAM usage continuously increasing with the browsing progress, eventually it ate me 2.5 GB VRAM (RAM usage won't change, because it hit the 2GB limit already)
 


<<<For saved page>>>
In the step 3, RAM usage increased very fast until reaching the 2GB limit, then the VRAM. Firefox tend to crash in this step. The page occupied about 1.3GB ram space after it stops loading.
In the step 4, VRAM usage still increasing with the browsing progress, ate 2.5 GB VRAM eventually.

Expected Results:  
With Chrome 12:
>>>For general browsing<<<
In the step 2, the RAM usage increased about 80M only, nothing special.
In the step 3, the VRAM usage continuously increasing with the browsing progress, eventually it ate me 1.5 GB VRAM. But by switching tab, the VRAM usage can be released completely.


<<<For saved page>>>
In the step 3, RAM usage increased about 80M only, the page showing about 3 times faster than Fx4.0.1
In the step 4, RAM/VRAM usage increasing with the browsing progress, ate 1.5 GB VRAM eventually. Also can be released by switching tab.

Just do it as Chrome or better.

The image decode area unit in Firefox seems to be "Tab", while it is "Screen" in Chrome, which means, Chrome only decode the images in the current screen and put the uncompressed data into RAM/VRAM while Firefox tends to decode all the images in the current tab and put those uncompressed data into RAM/VRAM (you can see this in about:memory images/chrome/used/uncompressed and other */uncompressed)

My Spec.
CPU    AMD X2 245
RAM    2GB
Plat.  Win7 32bit

__________________

That's why Firefox eats Gigabytes of memory while Chrome almost require nothing when you open a saved page.

If completely showing a same page, the VRAM usage in total of Firefox seems twice than Chrome.(Why?)
                
              VRAM before       VRAM after(download and browsed completely)
Firefox        1537 MB            4037 MB   (~2500M used by Firefox)
Chrome         1495 MB            3029 MB   (~1500M used by Chrome)

Comment 1

[byzod]

Attachment: Open - browse - close a saved page

Comment 2

[Tyler Downer [He/Him]]

Does a fresh profile help any?
http://support.mozilla.com/en-US/kb/Managing+profiles

Comment 3

[byzod]

(In reply to comment #2)
> Does a fresh profile help any?
> http://support.mozilla.com/en-US/kb/Managing+profiles

No. Tested with Fx4.0.1 with 32 extensions and Fx6.0a1 with 0 extension, eventually ~4GB VRAM(4.0.1) and 3.5GB VRAM(6.0a1).

BTW, the value of images/chrome/used/uncompressed is ~1.5GB

Comment 4

[Zvonimir1974]

I can replicate a problem with site from description and with few more image heavy sites so there is definitively problem with image heavy sites. I use FF4.0.1 on WinXP 32bit and when i reach 1.5GB FF chrashes. It looks to me like all images are decoded and like decodeondraw pref doesn't work or at least it doesn't work like I'm expecting.

If you open image heavy site in FF3.6.17 and scroll really fast from top to bottom and back a few times there will bi significant increase in memory usage (similar to 4.0.1) because all images have to be decoded but as soon as you stop scrolling things go back to normal.

Comment 5

[cplarosa]

I am able to easily crash Firefox 4.0.1 on my Windows XP system with 2GM RAM and no swap file.  Firefox seems to be running out of Image cache memory and crashing before it does a garbage collection.  It can easily be reproduced with a few lines of JavaScript and 40-50 large image files on a web server as follows:

var list = [
   "http://server/path/file1.jpg",
   "http://server/path/file2.jpg",
   ...
];
for (var i = 0; i < list.length; i++) {
   var image = new Image();
   image.src = list[i];
}

I think this is the same problem you're experiencing.  Image cache memory is not being garbage collected when memory is low, and so the browser crashes with an out-of-memory condition.

Comment 6

[Nicholas Nethercote [inactive]]

(In reply to comment #5)
> 
> var list = [
>    "http://server/path/file1.jpg",
>    "http://server/path/file2.jpg",
>    ...
> ];
> for (var i = 0; i < list.length; i++) {
>    var image = new Image();
>    image.src = list[i];
> }

cplarosa spun this off as bug 659220.  Both bugs probably have the same root cause.

Comment 7

[Nicholas Nethercote [inactive]]

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.