User Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0) Gecko/20100101 Firefox/6.0 Build ID: 20110811165603 Steps to reproduce: Went to http://www.facebook.com/photo.php?fbid=2289476761086&set=o.22158240846&type=1 and continue selecting 'next' and view memory usage. Actual results: Firefox continues to allocate pixmaps and does not free the blocks until the tab or window is closed. Expected results: Once a picture is no longer being displayed, the memory allocated to it should be freed.
Most of the memory was tied to images.content.used.uncompressed when looked at in about:memory.
Compare this when testing on the latest nightly build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-9.0a1.en-US.linux-i686.tar.bz2
Component: General → Networking: Cache
Product: Firefox → Core
QA Contact: general → networking.cache
Tested with the latest nightly build from the link and the problem is still being seen. Memory is still being consumed and not released unless the Facebook tab is closed or Firefox is shut down.
Component: Networking: Cache → ImageLib
QA Contact: networking.cache → imagelib
Memory is not restored on fennec after going to the site on a tab, viewing several pictures, and then closing the tab. Nightly ( http://hg.mozilla.org/mozilla-central/rev/e6591ea9b27b )
(In reply to Naoki Hirata :nhirata from comment #5) > Memory is not restored on fennec after going to the site on a tab, viewing > several pictures, and then closing the tab. The uncompressed numbers aren't going down after closing the tab? That's not what the other reporters saw.
Summary: Memory leak viewing large pictures in a Facebook slideshow → Many decompressed images from a Facebook slideshow aren't released until the tab is closed
So, I tested this on desktop. I went through a gallery of 171 images, and the image memory usage went up to 286MB. Then I went to about:memory and pressed GC and CC a few times, and the memory usage for images dropped again to what it was before (~15MB). I will also test this on mobile, but possibly on a tablet.
I could not reproduce this bug on http://touch.facebook.com at all. I don't think this is P1 any more, throwing it back into the pool.
Assignee: ehsan → nobody
Whiteboard: [MemShrink:P1] → [MemShrink]
If you open about:memory in a new tab and select GC and CC a few times or even "Minimize memory usage", the memory used by the Facebook slideshow is freed up. However, when you go back to the tab with the Facebook slideshow, memory usage goes right back up to where it was before it was minimized. Closing the tab with Facebook will clear the memory.
My assumption is that the images' decoded data is not being discarded because they're on the frontmost page. Jeff Muizelaar has done some experiments which prove that doing var img = new Image(); img.src = "http://foo/some.jpg"; causes the image to decode, which we think is wrong. Images should only be decoded when they're in the DOM. Solving that problem will likely solve the Facebook slideshow problem.
We probably need to decode enough to get size metadata in the situation of comment 10, but nothing else.
> var img = new Image(); > img.src = "http://foo/some.jpg"; I originally reported it in bug 366548 comment 19 (four years ago) but sadly just one symptom (gdi objects) wallpapered over. So in case someone wonders, it's a regression from FF 2.0.
Assignee: nobody → khuey
Whiteboard: [MemShrink] → [MemShrink:P2]
(In reply to Nicholas Nethercote [:njn] from comment #6) > (In reply to Naoki Hirata :nhirata from comment #5) > > Memory is not restored on fennec after going to the site on a tab, viewing > > several pictures, and then closing the tab. > > The uncompressed numbers aren't going down after closing the tab? That's > not what the other reporters saw. I tested this on the HTC flyer at the non-mobile page. To note, bug 680886. There's a plan to go to the full website for tablets, instead of the touch.facebook.com
I noted, with current Aurora, a really higher memory usage with Facebook photos. With older versions I could open a lot of photos in different tabs without problems, now after some photos Firefox becomes laggy and memory usage goes fastly to 2 GB! I don't think this is due to this bug or to bug 661304, because it seems a regression from Firefox 7. Sadly I can't give you many informations (this is why I didn't open a new bug), so I'll wait for these two bugs being resolved to see if the situation improves.
Bug 683290 will help a lot here, by allowing us to discard images for <img> elements that aren't actually in the document. That might be enough to call this fixed.
Depends on: 683290
(In reply to Marco Castelluccio (Away 8-15 Sept.) from comment #14) > I noted, with current Aurora, a really higher memory usage with Facebook > photos. With older versions I could open a lot of photos in different tabs > without problems, now after some photos Firefox becomes laggy and memory > usage goes fastly to 2 GB! > I don't think this is due to this bug or to bug 661304, because it seems a > regression from Firefox 7. > Sadly I can't give you many informations (this is why I didn't open a new > bug), so I'll wait for these two bugs being resolved to see if the situation > improves. I see this behavior on Firefox 6, so I don't think this is a recent regression.
(In reply to Kyle Huey [:khuey] (email@example.com) from comment #16) > I see this behavior on Firefox 6, so I don't think this is a recent > regression. By recent I mean somewhere between 5 and 8, because I don't remember this problem with Firefox 4. (Note that the issue I was pointing out is different from the one described in this bug: I get high memory usage with many Facebook photos opened, and this high memory usage isn't due to images but to layout, heap-unclassified and the JS compartments)
Note that some of the reason that you might see higher memory usage recently is due to Facebook itself: https://blog.facebook.com/blog.php?post=10150262684247131 The images are bigger now. They also decode progressively, but I'm not sure that has an effect on memory usage.
This should be fixed in tomorrow's Nightly. Testing would be appreciated. Dave, could we add a Mozmill test for this scenario?
Target Milestone: --- → mozilla10
8 years ago
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: [MemShrink:P2] → [MemShrink:P2][mozmill-test-needed][mozmill-endurance]
8 years ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Ok, not going to be fixed in tomorrow's nightly :-(
7 years ago
Duplicate of this bug: 761147
Should be fixed in tomorrow's nightly again!
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago → 7 years ago
Resolution: --- → FIXED
Target Milestone: mozilla10 → mozilla17
Michael Ryan, if you could confirm the fix with tomorrow's Nightly that would be very helpful! Thanks.
You need to log in before you can comment on or make changes to this bug.