Closed
Bug 975945
Opened 11 years ago
Closed 9 years ago
OS X memory spike on tab page
Categories
(Firefox :: Untriaged, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: bauermusic, Unassigned)
Details
(Whiteboard: [MemShrink:P2])
Attachments
(2 files)
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.
Reporter | ||
Comment 1•11 years ago
|
||
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/".
Reporter | ||
Comment 2•11 years ago
|
||
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.
Reporter | ||
Updated•11 years ago
|
Severity: normal → major
Reporter | ||
Comment 3•11 years ago
|
||
After testing on a Windows machine, it seems Windows is not effected. Macs only.
Comment 4•11 years ago
|
||
Can you reproduce this with a Firefox 28 beta build on OS X?
Flags: needinfo?(bauermusic)
Comment 5•11 years ago
|
||
This might be caused by the background capturing of thumbnails maybe? Can you tell us which links are shown on your new tab page?
Reporter | ||
Comment 6•11 years ago
|
||
@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.
Flags: needinfo?(bauermusic)
Reporter | ||
Comment 7•11 years ago
|
||
(Sorry for the late reply).
Tested on Firefox 28, problem persist. Again, this problem effect Firefox 28 as well.
Updated•11 years ago
|
Whiteboard: [MemShrink]
Comment 8•11 years ago
|
||
Can you please attach an about:memory report from when the memory is high? That may help identify the problem.
Updated•11 years ago
|
Whiteboard: [MemShrink] → [MemShrink:P2]
Comment 9•11 years ago
|
||
Tested on 10.9 with a nightly build and was not able to reproduce.
Reporter | ||
Comment 10•11 years ago
|
||
Reporter | ||
Comment 11•11 years ago
|
||
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•11 years ago
|
||
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 13•11 years ago
|
||
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•11 years ago
|
||
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?
Flags: needinfo?(ttaubert)
Comment 15•11 years ago
|
||
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?
Flags: needinfo?(ttaubert) → needinfo?(adw)
Comment 16•11 years ago
|
||
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?
Flags: needinfo?(adw)
Updated•11 years ago
|
Flags: firefox-backlog+
Updated•11 years ago
|
Flags: firefox-backlog+ → firefox-backlog-
Comment 17•9 years ago
|
||
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?
Flags: needinfo?(bauermusic)
Comment 18•9 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(bauermusic)
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•