Closed
Bug 679775
Opened 13 years ago
Closed 12 years ago
Many decompressed images from a Facebook slideshow aren't released until the tab is closed
Categories
(Core :: Graphics: ImageLib, defect)
Tracking
()
RESOLVED
FIXED
mozilla17
People
(Reporter: Michael.Ryan, Assigned: khuey)
References
(Depends on 1 open bug)
Details
(Whiteboard: [MemShrink:P2][mozmill-test-needed][mozmill-endurance])
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.
Reporter | ||
Comment 1•13 years ago
|
||
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
Related open bugs: bug 124608, bug 213391, bug 398983
Component: General → Networking: Cache
Product: Firefox → Core
QA Contact: general → networking.cache
Reporter | ||
Comment 4•13 years ago
|
||
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.
Updated•13 years ago
|
Whiteboard: [MemShrink]
Updated•13 years ago
|
Assignee: nobody → jmuizelaar
Updated•13 years ago
|
Component: Networking: Cache → ImageLib
QA Contact: networking.cache → imagelib
Updated•13 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•13 years ago
|
Assignee: jmuizelaar → ehsan
Updated•13 years ago
|
Whiteboard: [MemShrink] → [MemShrink:P1]
Updated•13 years ago
|
Depends on: image-suck
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 )
Comment 6•13 years ago
|
||
(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
Comment 7•13 years ago
|
||
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.
Comment 8•13 years ago
|
||
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]
Reporter | ||
Comment 9•13 years ago
|
||
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.
Comment 10•13 years ago
|
||
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.
Comment 11•13 years ago
|
||
We probably need to decode enough to get size metadata in the situation of comment 10, but nothing else.
Comment 12•13 years ago
|
||
> 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.
Updated•13 years ago
|
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
Comment 14•13 years ago
|
||
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.
Assignee | ||
Comment 15•13 years ago
|
||
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
Assignee | ||
Comment 16•13 years ago
|
||
(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.
Comment 17•13 years ago
|
||
(In reply to Kyle Huey [:khuey] (khuey@mozilla.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)
Comment 18•13 years ago
|
||
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.
Assignee | ||
Comment 19•13 years ago
|
||
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
Assignee | ||
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Whiteboard: [MemShrink:P2] → [MemShrink:P2][mozmill-test-needed][mozmill-endurance]
Assignee | ||
Updated•13 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 20•13 years ago
|
||
Ok, not going to be fixed in tomorrow's nightly :-(
Assignee | ||
Comment 22•12 years ago
|
||
Should be fixed in tomorrow's nightly again!
Status: REOPENED → RESOLVED
Closed: 13 years ago → 12 years ago
Resolution: --- → FIXED
Target Milestone: mozilla10 → mozilla17
Comment 23•12 years ago
|
||
\o/
Comment 24•12 years ago
|
||
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.
Description
•