291519 - Memory used by images are not cleaned up when tab is closed

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[mrdoommaster]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

The problem was found while using the FlashGot plugin. I emailed the author of
this plugin stating the memory leaks, and he said this is a problem with
firefox, NOT his plugin. This makes sense too:

---------------------------------
I was just recently using FlashGot v0.5.8 along with the most recent version of
FlashGet to obtain a huge amount of picture files from various galleries.

I followed the following process:

1) I would right click a picture, and "Build Gallery"
2) I would fill the 'Preview' edit control with the actual HTTP address to the
FULL SIZED picture, I didn’t want to use the thumbnail/source combination.
3) Thirdly, after the gallery was built, I right clicked in a blank area and
clicked "Flashgot All".
4) FlashGet then began processing a batch of around 500 pictures in one go.

I followed the above steps on several galleries, which range from 10 to 500
pictures. It depends.

Anyhow, after obtaining about 1000 picture files via your plugin and flashget, I
noticed my computer lagging INCREDIBLY! I checked my task manager to find that
firefox was consuming 1.1GB of my memory! I have 1.5GB Total.
---------------------------------

Reproducible: Always

Steps to Reproduce:
See 'Details' for the steps.

Actual Results:  
See 'Details' for results

Expected Results:  
It should have cleaned up the used memory!

I have a screenshot of my task manager I can provide to prove the actual memory
usage of the application at the time it was noticed. Email me at
[e-mail] if you wish for me to send you this screenshot, I'd be
more than happy.

Comment 1

[mrdoommaster]

Attachment: Screenshot of memory consumption

This screenshot shows the results of the huge memory leaks after about 1000
full-size images were displayed within a few hours of using Firefox.

Comment 2

[Matthias Versen [:Matti]]

Reporter:
Please test a curent trunk developer build.
FF1.0.3 is based on a very old Gecko and a bug report for FF1.0.3 doesn't help.

Comment 3

[spam.deluxe]

I experience the same memory consumption with and WITHOUT FlashGot. However, in
the end this report should be a duplicate of BUG #249469.

Comment 4

[Mitchell Keith Bloch]

I have encountered similar problems: very recent builds of Deer Park Alpha 2 use over a gig of ram and nearly completely crash my system using either Windows XP SP2 or Debian Linux.  (I only /have/ a gig of RAM... flooding my swap space != good)  All I'm doing is loading and unloading various pages containing image files.  In Linux, it is so bad that I have to force power down and reboot.

In task managers for both operating systems, I can watch the memory usage climb at a rate of several megabytes per second when I don't even appear to be doing anything any more.

I'm sure someone with knowledge about the Linux and Windows kernels and their respective swapping techniques could explain why it is worse in Linux...

Comment 5

[Mitchell Keith Bloch]

It seems like you can get the base memory usage to rise about a minimum of 30 MB for each time you 

1) Google image search whatever "random" word that pops into your head
2) Open all links on the first page in tabs (all 25 of them)
3) Wait for said links to load
4) Close all the tabs you just opened

Most of the images you find this way aren't too big though...  It can be worse.  Nonetheless, doing this several times without closing the browser, just watching the task manager should show you that a leak is there.

While I know nothing about the actual implementation of Mozilla (Browser) / Firefox, I imagine that each time a page is rendered, some surface that is generated somewhere along the way is not properly freed back to memory.  Hence, if a page has many large images, the page will be rerendered each time one of the images loads slightly further.  Many renders + small leak per render = large memory leak.

//Sidenote: minimizing does nothing to help this as suggested for similar sounding problems

Comment 6

[Nickolay_Ponomarev]

See http://dbaron.org/log/2006-01#e20060114a

Would be nice if someone ran a recent trunk build with aforementioned logging enabled and reported if the leaks actually happen, and if so, what are the exact steps to reproduce given a clean profile with no extensions.

Comment 7

[Mitchell Keith Bloch]

Well, I really have no idea if this is an image problem, or just a problem with pages in general (tabbed browsing?), but these are the steps:

1. Install /nightly/latest-trunk/firefox-1.6a1.en-US.linux-i686.installer.tar.gz (January 15, 2006)
2. Ensure that all there are no leftovers in the plugins directory, erase/move .mozilla elsewhere.  Check preferences to make sure no plugins are in use, extensions are gone, etc...  All clear.
3. "
1) Google image search whatever "random" word that pops into your head
2) Open all links on the first page in tabs (all 25 of them)
3) Wait for said links to load
4) Close all the tabs you just opened
"

When I ran these steps just now with the "random" word 'peanut', firefox-bin's Memory column in the Gnome System Monitor climbed from 84 MB to 191 MB.  Right now I only have two tabs open in one window, both pointing to small pages on the mozilla.org site, and I've climbed up to 194.4 MB.

Comment 8

[Samuel Sidler (old account; do not CC)]

This bug is probably a duplicate of bug 249469. However, now it could also be undo close tab setting aside some memory for faster undoing. Either way, it's either WORKSFORME or WORKSASINTENDED (which isn't a real resolution). I'm going to close this bug as WORKSFORME.

If you can reproduce this using Firefox 2.0.0.3 with a new profile (specifically relating to memory use of images not being released when tabs are closed) and can prove it's not related to the undo close tab feature, please file a new bug with detailed steps to reproduce and information on how you're seeing this. Also see comment 6 for a link on actually finding the leak.

http://kb.mozillazine.org/Profile_Manager