975945 - OS X memory spike on tab page

Status: RESOLVED INCOMPLETE

(Firefox :: Untriaged, defect)

Description

[bauermusic]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20140212131424

Steps to reproduce:

Open a new empty tab. 
Click on "Open new tab page" (on upper right of page). Or have it (tab page with sites links) already setup as open.


Actual results:

RAM spike to max, (in my case, 1.8GB) causing the whole OS X to become unresponsive.

- This happen on Safe Mode!
- I have created a new profile and deleted the old one. > Problem was fixed for 2 days and came back.

This seems like one of the items/links/sites in the empty tab page that is causing this. I would try to isolate them, but my machine freezes and become completely unresponsive in seconds.


Expected results:

Not having to force shot my Mac.

Comment 1

[bauermusic]

More info. After deleting all history, no memory problems, as "Tab page" is now empty.

This is caused by one of the items in "Tab page". A possible suspect is "parse.com/".

Comment 2

[bauermusic]

Can reproduce.

1. Open (new tab) tab bar.
2. Open a second window and go to parse.com site.
3. Drag to link the page to the 'tab bar' page.

Comment 3

[bauermusic]

After testing on a Windows machine, it seems Windows is not effected. Macs only.

Comment 4

[Nathan Froyd [:froydnj]]

Can you reproduce this with a Firefox 28 beta build on OS X?

Comment 5

[Tim Taubert [:ttaubert] (inactive)]

This might be caused by the background capturing of thumbnails maybe? Can you tell us which links are shown on your new tab page?

Comment 6

[bauermusic]

@Tim Will do so later on today. 
It is the parse.com one, when I remove it, everything is fine. When I add it back to tap page it start grabbing RAM. 
Didn't think of trying Firefox 28, will do so tomorrow.

Comment 7

[bauermusic]

(Sorry for the late reply). 

Tested on Firefox 28, problem persist. Again, this problem effect Firefox 28 as well.

Comment 8

[Andrew McCreight [:mccr8]]

Can you please attach an about:memory report from when the memory is high?  That may help identify the problem.

Comment 9

[Eric Rahm [:erahm]]

Tested on 10.9 with a nightly build and was not able to reproduce.

Comment 10

[bauermusic]

Attachment: Memory-Report

Comment 11

[bauermusic]

Attachment: BEFORE - Memory report before openning new tab

I've added this file for comparison. This is taken a second before opening a new tab.

This file can be compare to previous attachment:
https://bugzilla.mozilla.org/attachment.cgi?id=8393315&action=edit

Comment 12

[Nathan Froyd [:froydnj]]

So the thing that really jumps out from attachment 8393315 [details] is this:

├──287.64 MB (76.43%) ── heap-unclassified

but there doesn't seem to be any identifying information as to what page is being visited when that about:memory snapshot is being taken.  I assume it's parse.com?

I can verify the behavior the original reporter is seeing on OS X 10.7.5 with Firefox 28.  I haven't tried Nightly yet.  In slightly more verbose terms, this is what I did:

1. Open a new tab.
2. Open a new window and visit parse.com in it.  (I suspect the website doesn't really matter, but we'll stick with this for now.)
3. Click and hold on the lock icon in the URL bar and drag+drop into the new tab that you opened in step 1, so as to place a parse.com tile on the new tab page.  If you don't see the tiles shift around, just try again.
4. Observe memory usage go through the roof.  The 'Firefox Plugin Process' in Activity Monitor had a "real memory use" of ~3.6GB temporarily, though it did seem to come down after a little while (~30 seconds).  The Firefox process itself also grows a bit, though not as drastically.

Comment 13

[Nathan Froyd [:froydnj]]

The heap-unclassified also appears to stick around for a while, so we might have a bona fide leak on our hands.  Going to try and track this down with DMD.

Comment 14

[Nathan Froyd [:froydnj]]

Can't reproduce in Nightly on OS 10.7.5.  Apparently we've fixed things along the way?  Tim, do you know of anything related to the new tab page that might have changed in the 28-31 time period?

Comment 15

[Tim Taubert [:ttaubert] (inactive)]

Hmm... there have been a few changes to how we capture thumbnails. As mentioned, I suggested this might have something to do with OOP background capturing of thumbnails. Drew might know?

Comment 16

[Drew Willcoxon :adw]

The Firefox Plugin Process activity indicates it's something to do with the capturing of missing thumbnails in the hidden, OOP browser that we do when about:newtab is opened.  I looked through the thumbnail bugs that I could find from that period.  There aren't many, and none made any related changes.  Maybe something changed in OOP browsers?

Comment 17

[ovidiu boca[:Ovidiu]]

Hi,
I tested with Firefox Nightly 46.0a1 on Mac OS X 10.10 following the steps from comment 12, and I could't reproduce the issue.  
Reporter, can you reproduce this problem with the latest version?

Comment 18

[ovidiu boca[:Ovidiu]]

Hi,
Marking this as Resolved: Incomplete due to the lack of response from the reporter.
Reporter, please feel free to reopen it if you are still having this issue on the latest Firefox version.