User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0 Build ID: 20170612121707 Steps to reproduce: I have ~50 tabs opened and if firefox has been running for a while main (UI) process starts freezing for prolonged periods of times. It looks like problem is exacerbated by some websites, especially if they are constantly reloading data. I seem to often see this problem when I leave tab with newrelic graphs (newrelic.com) or graphite dashboard (grahiteapp.com) opened overnight. It also looks like closing those tabs and then clicking 'minimize memory usage' on 'about:memory' temporarily resolves the problem Actual results: firefox freezes Expected results: firefox should not freeze.
Please follow the steps here "https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem#Setting_up_the_Gecko_Profiler_extension" to get your performance profile so we can see exactly what is going on.
Justin, does it have to be nightly or can it be release FF version? It takes some time for a problem to appear which means I would have to 'work' in nightly - I was hoping to avoid it unless nessesary.
no you can use release FF.
Here's link for profile: http://bit.ly/2tmvBDc. It looks like there is this repeating pattern of being stuck in PCookieService::Msg_GetCookieString for a few seconds - which is I guess #1331680. Delays there seem to be about 13 seconds - which is probably not very good. Main thread seem to be spending a lot of time in nsJSContext::RunCycleCollectorSlice - which I guess would sort of align with the fact that minimizing memory consumption helps. On the related note I should point out that when this profile was collected main process had resident size of ~4G. Please let me know if I can provide any more information. Thanks!
Hey Mike I know it is a Release profile but could you help here?
Nikolay Martynov's analysis is spot on - the content processes are blocked on sync messages to get cookies (yes, that's bug 1331680), and the main thread in the parent process is busy doing a very long cycle collection. Most likely something is leaking - either a page (least likely, since the CC is happening in the parent process), an add-on, or Firefox itself. When in this state, an about:memory report would be most useful, I think.
Created attachment 8890152 [details] memory-report.json.gz Attaching memory report when problem exists. Also, it looks like that opening large google docs slide deck (with lots of images) and leaving it opened makes problem appear sooner.
There is roughly 2GB in the parent process under "heap unclassified". Smells like a leak. Are you able to reproduce this with your add-ons disabled?
mconley, if this is a problem in sync cookies, can we close this now that bug 1331680 landed?
Component: Untriaged → Untriaged
Product: Firefox → Core
Sorry, didn't mean to move this one.
Component: Untriaged → Untriaged
Product: Core → Firefox
(In reply to Joe Hildebrand [:hildjj] (UTC-6) from comment #9) > mconley, if this is a problem in sync cookies, can we close this now that > bug 1331680 landed? That, and the fact that we haven't heard back from the reporter, I think we can close this one out as INCOMPLETE.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 months ago
Resolution: --- → INCOMPLETE
@Mike, I'm sorry I didn't get back to you. Unfortunately the bug is reproducible only after a few days of run - and running a few days without plugins is hard. I was waiting to see if I can still reproduce the problem with only webextentions (and no legacy plugins). I'll reply (and I guess reopen) this bug if I can reproduce the problem. Thanks!
Nikolay, the sync cookies work only landed on nightly a few days ago. If you can reproduce with a nightly from today forward, NI me or mconley, and we'll reopen this bug - it will be high priority for us!
You need to log in before you can comment on or make changes to this bug.