Last Comment Bug 679775 - Many decompressed images from a Facebook slideshow aren't released until the tab is closed
: Many decompressed images from a Facebook slideshow aren't released until the ...
Status: RESOLVED FIXED
[MemShrink:P2][mozmill-test-needed][m...
:
Product: Core
Classification: Components
Component: ImageLib (show other bugs)
: 6 Branch
: x86 Linux
: -- normal with 2 votes (vote)
: mozilla17
Assigned To: Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary)
:
Mentors:
: 761147 (view as bug list)
Depends on: image-suck 683290
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-17 10:24 PDT by Michael.Ryan
Modified: 2012-08-15 16:25 PDT (History)
21 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Michael.Ryan 2011-08-17 10:24:44 PDT
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.
Comment 1 Michael.Ryan 2011-08-17 10:26:28 PDT
Most of the memory was tied to images.content.used.uncompressed when looked at in about:memory.
Comment 2 Mardeg 2011-08-17 10:35:34 PDT
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
Comment 3 Mardeg 2011-08-17 10:38:11 PDT
Related open bugs: bug 124608, bug 213391, bug 398983
Comment 4 Michael.Ryan 2011-08-18 12:49:15 PDT
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.
Comment 5 Naoki Hirata :nhirata (please use needinfo instead of cc) 2011-08-30 13:43:23 PDT
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 Nicholas Nethercote [:njn] 2011-08-30 17:46:04 PDT
(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.
Comment 7 :Ehsan Akhgari 2011-08-31 08:39:35 PDT
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 :Ehsan Akhgari 2011-08-31 08:46:18 PDT
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.
Comment 9 Michael.Ryan 2011-08-31 10:13:01 PDT
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 Joe Drew (not getting mail) 2011-08-31 10:20:25 PDT
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 Boris Zbarsky [:bz] 2011-08-31 10:35:53 PDT
We probably need to decode enough to get size metadata in the situation of comment 10, but nothing else.
Comment 12 Radek 'sysKin' Czyz 2011-08-31 18:43:36 PDT
>   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.
Comment 13 Naoki Hirata :nhirata (please use needinfo instead of cc) 2011-09-06 13:21:52 PDT
(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 Marco Castelluccio [:marco] 2011-09-06 16:15:33 PDT
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.
Comment 15 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-09-07 04:19:50 PDT
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.
Comment 16 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-09-07 04:20:38 PDT
(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 Marco Castelluccio [:marco] 2011-09-07 04:39:29 PDT
(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 Daniel Cater 2011-09-27 17:44:37 PDT
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.
Comment 19 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-10-10 09:23:21 PDT
This should be fixed in tomorrow's Nightly.  Testing would be appreciated.

Dave, could we add a Mozmill test for this scenario?
Comment 20 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-10-10 13:59:43 PDT
Ok, not going to be fixed in tomorrow's nightly :-(
Comment 21 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2012-06-04 11:23:28 PDT
*** Bug 761147 has been marked as a duplicate of this bug. ***
Comment 22 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2012-08-15 13:39:46 PDT
Should be fixed in tomorrow's nightly again!
Comment 23 Joe Drew (not getting mail) 2012-08-15 14:52:55 PDT
\o/
Comment 24 Nicholas Nethercote [:njn] 2012-08-15 16:25:23 PDT
Michael Ryan, if you could confirm the fix with tomorrow's Nightly that would be very helpful!  Thanks.

Note You need to log in before you can comment on or make changes to this bug.