User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release) Build ID: 20131030131730 Steps to reproduce: Just start firefox Actual results: 2.5Gb of ram eaten, system in swap. This is not when I started to even do anything. If I open some pages, the situation goes much worse. Expected results: 10 times less memory should be eaten.

Yes, I tried the safe mode - same results. No, I haven't tried the new profile - I don't want to do that. This is like re-installing windows every now and then. I attached the memory profile from about:memory. Whatever other info you need - please ask. This was not the case before. Only the latest firefox releases (like from around 18, I think) started to be so memory hungry.

You need to try the new profile, it doesn't erase your previous profile. Profile manager allows to switch between profiles easily. https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

--- $ firefox -P (process:18121): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed $ --- And firefox started a new session with the same memory consumption. Attaching a new memory profile. While it didn't kill my profile entirely, it have killed the previous session info, so the RestoreSession dialog no longer pops up. firefox is so slow that I always have a RestoreSession dialog at startup: I don't have time to wait for a clean shutdown, so I already got used to the restoresession being my startup page. Now it have been killed... :(

Here are the most important parts for the memory-report-P.json.gz attachment: 2,633.91 MB (100.0%) -- explicit ├──1,128.88 MB (42.86%) ── heap-unclassified ├────652.00 MB (24.75%) -- js-non-window │ ├──630.65 MB (23.94%) -- zones │ │ ├──615.97 MB (23.39%) -- zone(0x7fbb9afd7800) │ │ │ ├──499.77 MB (18.97%) ++ string-chars │ │ │ ├───52.88 MB (02.01%) ++ gc-heap │ │ │ ├───34.31 MB (01.30%) ++ (343 tiny) │ │ │ └───29.01 MB (01.10%) ++ compartment([System Principal], resource:///modules/sessionstore/SessionStore.jsm) │ │ └───14.68 MB (00.56%) ++ (12 tiny) │ └───21.35 MB (00.81%) ++ (2 tiny) ├────324.13 MB (12.31%) -- workers/workers() │ ├──320.37 MB (12.16%) -- worker(resource:///modules/sessionstore/SessionWorker.js, 0x7fbb8e358000) │ │ ├──319.01 MB (12.11%) -- zone(0x7fbb8d46f000) │ │ │ ├──318.55 MB (12.09%) ── string-chars/huge/string(length=167012620, "{"windows":[{"tabs":[{"entries"...") │ │ │ └────0.46 MB (00.02%) ++ (4 tiny) │ │ └────1.37 MB (00.05%) ++ (4 tiny) │ └────3.76 MB (00.14%) ++ (2 tiny) ├────315.38 MB (11.97%) -- window-objects │ ├──192.77 MB (07.32%) ++ top(https://www.facebook.com/messages/alexandra.murashova, id=46) │ ├───55.88 MB (02.12%) ++ (20 tiny) │ ├───37.58 MB (01.43%) ++ top(https://www.facebook.com/photo.php?fbid=4177766477188&set=pb.1075147597.-2207520000.1383559000.&type=3&theater, id=8) │ └───29.16 MB (01.11%) ++ top(about:memory, id=1112) ├────153.41 MB (05.82%) -- heap-overhead │ ├──150.22 MB (05.70%) ── waste │ └────3.19 MB (00.12%) ++ (2 tiny) └─────60.10 MB (02.28%) ++ (20 tiny) There are several anomalous things here. 1,128.88 MB of heap-unclassified is terrible :( Stas, you're on x86-64 Linux -- are you willing to do some deeper investigation? If you could run a DMD-enabled build of Firefox (instructions are at https://wiki.mozilla.org/Performance/MemShrink/DMD) that would be an enormous help. We won't get any insight into this part of the memory consumption without data from DMD. However, it does require building Firefox yourself, which is intimidating if you haven't done it before. (Instructions are at https://developer.mozilla.org/en-US/docs/Simple_Firefox_build.) 499.77 MB of string-chars is high for one zone. In the "(343 tiny)" sub-tree there are lots of system principal compartments, but there are also lots of facebook.com compartments. That's surprising... I thought system and user compartments wouldn't be combined in a single zone like that. billm, is that right? A 318.55 MB string for session restore is also terrible. How many tabs were in this session? This doesn't look like data from a new profile, AFAICT. How big is the sessionstore.js file in your profile? (You can find your profile directory with these instructions: http://kb.mozillazine.org/Profile_folder_-_Firefox#Mac.) I wonder if this correlates with the high heap-unclassified value. I wonder if providing some of the data from the profile would allow one of us to reproduce the problem.

> 499.77 MB of string-chars is high for one zone. In the "(343 tiny)" sub-tree there are lots > of system principal compartments, but there are also lots of facebook.com compartments. > That's surprising... I thought system and user compartments wouldn't be combined in a single > zone like that. billm, is that right? It's possible that we're passing SystemZone in someplace where we shouldn't be. It's hard to debug from the memory dump though. I only see system compartments in my own about:memory.

Bug 669034 comment 70 reminded me a lot of this bug.

OK, I'll be building FF from sources - I simply have no other choice, because, while before it was terribly slow by itself, these days it runs the entire system into swap. But, since this is time-consuming, it will have to wait till the week end. To speed up the process, you can publish a binary builds for me. Or, in case you have some "friends" at RedHat bugzilla, maybe you can ask them to do an rpm build, which other linux users will be happy to try too. I am not sure how the facebook even came into play. The -P log was done without opening a single page, and without a sessionrestore page. It was just a plain empty page... But the first log, without -P, was indeed done with the sessionrestore page being displayed, and having some facebook pages to restore, but it was also done before clicking "Restore" button. So to your question about how many tabs, I am a bit confused. Lets say that sessionrestore dialog, which have something to do only with the first log (which you haven't looked into, not -P), had to restore about 7 tabs on facebook, and about 3-4 separate windows, like google, yandex etc. BUT, let me assure you that every facebook tab slows firefox much more than 20 tabs from any other site. Yes, it seems the profile failed to became "new", even with -P. Please note the error that it thrown on me: --- $ firefox -P (process:18121): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed $ --- So I think it failed to create a new profile, but it have also bypassed a sessionrestore window. Yet you claim even the -P log have something to do with sessionrestore and facebook, so I am confused. I will look up the size of sessionrestore.js and will let you know later today. Please tell me what parts of the profile I will need to share with you. Bug 669034 certainly have something to do with my situation. At least it mentions stalls for 3sec. Let me say that I have stall for about 30sec when I just type a single char in a FB messaging panel. And it is not related to swapping, it is something FB-specific.

(In reply to Stas Sergeev from comment #8) > Bug 669034 certainly have something to do with my > situation. At least it mentions stalls for 3sec. > Let me say that I have stall for about 30sec when > I just type a single char in a FB messaging panel. I had this exact same behavior as well. It's the session-collecting task in the main thread. > And it is not related to swapping, it is something > FB-specific. FB chat leaks a bunch of little URLs that add up over time.

Do you have Social API (Facebook Messenger for Firefox) installed? If so, please disable. Also, try to disable the Facebook chat (within the website) and see if this improves the situation (you may need to close the FB tabs, wait a bit so the new sessionrestore files are written, close Firefox, reopen & restore, then you can reopen FB sites).

Nicholas Nethercote: My sessionrestore.js is 163Mb. I'd like to send it to you, but even bzip2 doesn't make it much smaller. Would you please provide some FTP or something? In this case please mail me an upload URL privately: I don't want to make this file too much public, but for reproducing the problem its perfectly fine to upload it somewhere.

(In reply to Florian Bender from comment #10) > Do you have Social API (Facebook Messenger for Firefox) installed? If so, > please disable. No any FB-specific plugins installed, and I tried the safe mode too. > Also, try to disable the Facebook chat (within the website) and see if this > improves the situation (you may need to close the FB tabs, wait a bit so the > new sessionrestore files are written, close Firefox, reopen & restore, then > you can reopen FB sites). Disabled the FB chat, closed firefox and renamed sessionrestore.js. So far no changes... There are probably more than one chat. I am using the messaging there, rather than chat. And in fact, even though I have renamed sessionrestore.js while firefox was closed, it have re-created it to the same size! It seems to have some backups somewhere... and indeed, I can see many sessionrestore-N.js files, where N is different numbers.

You can use this script to print out large python string keys from your sessionstore.js. Use like this: cd .mozilla/firefox/*default/ ; python large_obj.py | sort -n

(In reply to C from comment #13) > Created attachment 827587 [details] > large_obj.py > > You can use this script to print out large python string keys from your > sessionstore.js. Use like this: > > cd .mozilla/firefox/*default/ ; python large_obj.py | sort -n E.g., here is my top 5: 1030 /windows[0]/tabs[4]/storage/https://www.facebook.com/_ua_log 1159 /windows[0]/cookies[148]/value 1159 /windows[0]/cookies[42]/value 1159 /windows[0]/cookies[95]/value 1440 /_closedWindows[1]/_closedTabs[1]/state/storage/http://runkeeper.com/History.store

What does it give us? Anyway, the output of your script is attached.

(In reply to Stas Sergeev from comment #15) > Created attachment 827594 [details] > a.txt.bz2 > > What does it give us? > Anyway, the output of your script is attached. For example (and you have tons of these): 1042 /windows[2]/tabs[0]/entries[2]/children[1126]/url ^^^^ ^^^^ You have an open tab with thousands (>=1126) of children (probably anon. facebook iframes) w/ ~1kB (1042) character URLs. This is likely leading to the RAM usage and huge stalls. If I had to guess, those are all facebook.com/ai.php, in which case I suggest installing adblockplus and adding the url filter: ||facebook.com/ai.php?* It doesn't seem to affect my Facebook use in any way other than not killing firefox.

67705 /windows[0]/tabs[0]/storage/https://www.google.ru/web::sbav=on.2,or.r_qf.&fp=4fb487d460d8817f&newwindow=1&psj=1&q=glib-critical **: g_slice_set_config: assertion `sys_page_size == 0' failed 78575 /windows[0]/tabs[0]/storage/https://www.google.ru/web::c4b910764fd71d087 79114 /windows[0]/tabs[0]/storage/https://www.google.ru/web::c4fb487d460d8817f These are also quite large -- it shows that Google is storing ~220 kB in your local/session storage, all of which gets persisted to sessionstore.js. But the majority is probably the Facebook URLs.

(In reply to C from comment #16) > (In reply to Stas Sergeev from comment #15) > > What does it give us? > > If I had to guess, those are all facebook.com/ai.php, in which case I > suggest installing adblockplus and adding the url filter: > > ||facebook.com/ai.php?* > > It doesn't seem to affect my Facebook use in any way other than not killing > firefox. Sorry, that doesn't actually fix your current session. But it prevents it from getting worse. I found the refreshing the facebook chat tab cleared the URLs for me.

Thanks for your input! I'll try to reset the tabs and installing adblock, but I'll first try to build firefox with memory profiling enabled. I worry if I screw up my current test-case, then this bug will simply be closed. I am sure there are things to fix here. If, as you say, not only FB pollutes the restoresession, but google (and other sites) too, then surely firefox needs to be fixed. Why chromium doesn't absorb all the garbage like this, while firefox does?

(In reply to Stas Sergeev from comment #11) > Nicholas Nethercote: > My sessionrestore.js is 163Mb. > I'd like to send it to you, but even bzip2 doesn't > make it much smaller. > Would you please provide some FTP or something? > In this case please mail me an upload URL privately: > I don't want to make this file too much public, but > for reproducing the problem its perfectly fine to > upload it somewhere. Fair enough... I'm having trouble thinking how to transfer it. I don't suppose you have a personal website that can handle a file of that size? You could make an obscure URL for the file and then email it to me...

Bug 934935 is closely related to this one.

(In reply to Nicholas Nethercote [:njn] from comment #21) > Bug 934935 is closely related to this one. Yes, but probably not quite. I wonder if much more can be done than fixing FB. - There are memory oddities you mentioned in Comment 5, that can probably be fixed. - FB leaks resources... OK but firefox already asks the user to stop the script if it is eating too much of the CPU. Why not to ask the user to stop the script also if some other resources are wasted, like too many memory used, or too many iframes created? IMHO forefox should properly account the resources inside the sandbox it creates, so that no any stupid script can run the whole system into swap. - There are stalls mentioned in comment 9. These stalls completely freeze the entire firefox GUI on every opened FF windows, not only on an FB site! The OS then asks the user to kill the process because it "does not respond". This indicates that perhaps FF is not using threading efficiently, because any stupid site should not lock up the entire FF gui in all of its windows. So I think fixing the problem the Bug934935's way is very much insufficient. FB has bugs - whatever, many sites has bugs. This cannot lead to the global OS swapouts of everything.

Bug 934935 says that FB spams sessionstore.js. Is my understanding correct that even without restarting sessions, if firefox has an FB page opened, it will eventually run out of memory because of those leaked iframes? Or is this specific only to spamming sessionstore.js?

(In reply to Stas Sergeev from comment #23) > Bug 934935 says that FB spams sessionstore.js. > Is my understanding correct that even without > restarting sessions, if firefox has an FB page > opened, it will eventually run out of memory > because of those leaked iframes? Or is this > specific only to spamming sessionstore.js? sessionstore.js is serialized from in-memory objects. Leaks in sessionstore.js represent leaks in memory as well. so yes, a FB page open will eventually run the system out of memory because of those leaked iframes.

Nicholas, since you've got my sessionrestore.js, there is probably no need of me to recompile firefox any more?

> Nicholas, since you've got my > sessionrestore.js, there is probably no > need of me to recompile firefox any more? True. Thanks!

OK, so I tried the suggested workarounds. - Refreshing FB tabs - no relief. - Closing all FB tabs and waiting for swapins: this helped only partially. Still over 1Gb is consumed! New memory log is attached.

Unfortunately, session store preserves information about closed tabs. Try setting the sessionstore.max_tabs_undo pref to 0 in about:config. Then open about:memory, click "Minimize memory usage", and see if it goes down.

Just a tiny bit. New log attached. Any other things to try?

How big is your sessionstore.js file now?

Too late, I have already restarted firefox... Now my sessionstore.js is 1Mb, and the memory usage have dropped to normal. Which likely means there are also the leaks, if the restart was needed.

I think this can be dup'd to bug 934935, since the Facebook issue appears to be clearly the problem.