I have been noticing that this has been kinda worse as time passes, but only now I think it has stepped over a threshold that is too much to handle. Problem: When firefox navigates to a page that includes visible inputs for text (input@type=text, input@type=file or textarea) firefox allocates some extra, quite noticeable, amount of memory. It may hang a bit, but nothing that seem problematic or annoying. Then, when I try writting something to the textarea or the text inputs it keep hanging and most text I write when it hangs is lost in the input buffer. I need to re-write the text that was not written; and I also need to keep checking if firefox was hanging, or not, while I was writting. Troubleshooting tries: I made a clone of my firefox profile and I spent some hours following the guides: http://kb.mozillazine.org/Firefox_hangs http://kb.mozillazine.org/Standard_diagnostic_-_Firefox After 3 tries, I restarted the troubleshooting in -safe-mode and did all the rest only in -safe-mode so that the addons + plugins + my changed settings would not interfere with the testing. Tabs: I have about 40 tabs open (I don't know the real number) spread through 5 tab groups and with 7 tabs in the current group. Memory: I've noticed that, in my normal use, firefox uses between +-900MB (normal state) but can easily escalate to +-1400MB when I'm using textareas, for example. In -safe-mode, the "base" memory was 600-800MB and the peak was +-1100MB This is information given by the resource manager in the commit tab. One thing I notice that seems to be happening is that firefox keeps doing heavy GC work over and over. I state that because the memory just keeps on fluctuating and never stays +- still. Platform: I'm using win6.1 x64 running on an Intel core 2 duo (does not support hiper-threading). Possible conflicting software: I use Ms Security Essentials and I use windows firewall. How to reproduce: I don't really know any background steps to reproduce this. Probably the main thing here is to have a "decent" number of tabs opened and a computer that is not much powerful and is under a considerable amount of use.

Provide memory log (about:memory?verbose) when the memory use is high.

Here's an example verbose memdump as requested. Unfortunately I'm unable to get the value when it reaches the peak because firefox is unresponsive at those times.

Any updates on this?

(In reply to brunoais from comment #0) > I don't really know any background steps to reproduce this. Probably the > main thing here is to have a "decent" number of tabs opened and a computer > that is not much powerful and is under a considerable amount of use. Without proper STR, it will not help. :/ Did you try to repro the issue with a fresh profile (no add-on) and a decent number of tabs opened?

I can try!

¦ ¦ ¦ +--181,396,808 B (11.90%) -- compartment([System Principal], resource://lazarus/aes.js) Looks like some sort of addon problem here.

Kris, can we get in touch with the add-on author? https://addons.mozilla.org/En-us/firefox/addon/lazarus-form-recovery/

I sent them a message via AMO. Their account is registered to a generic support email, so I can't CC them here.

Seems like... There's more here, but I'm not sure. Seems like the peek is also caused by more than only lazarus. If I turn lazarus off (not using lazarus interface, by using firefox's interface). The problem persists but the halts last less. I've been checking firefox's behaviour using Window's windows resource manager. Memory usage and how it uses it, disk usage and which files are open and connections open. From my 5 day search there (as about:memory was not giving snapshots of the correct times because ff was unresponsive) Seems like there's a competition for the sessionrestore.tmp file. Lazarus also has some I/O but nothing special. What's special is the sessionstore.js.tmp I/O. It starts using many file handlers. I've seen numbers like 10 handlers, but the most usual ammount were about 5 handlers. I don't know if it's true, but this seems to be a choak caused by the session store + lazarus fighting for something. Sessionstore alone makes firefox unresponsive. I also made another test. I increased the number of tabs I was using by a decent amount (about 400 tabs, something that sometimes happens to me) and it became really serious unresponsive times! I really mean... ~10 full secs of unresponsiveness for every ~6 secs of responsiveness while writting to textareas with lazarus deactivated and ~15 secs of unresponsiveness with lazarus activated. I've personally checked the memory data that about:memory is displaying. It's no real use, the data is from after the unresponsiveness and I can't really predict when it will be unresponsive. not confirmed yet: Seems like sessionstore system is increasing the memory used by too much. With lazarus, sometimes memory used reaches ~2GB, without lazarus, memory has peaks of ~1,7GB. I still need to test more about this to confirm what I'm stating in this paragraph.

> There's more here, but I'm not sure. Do you have these problems in safe mode? It could be that another extension is causing problems, too.

I got this by pure chance why I was trying to remove memory between unresponsiveness while in -safe-mode because it was using ~1,7GB Unfortunately this is not the verbose output but I think it might show that the sessionstore was using too much memory. I tried then, for 2hrs to get a verbose one with about the same but i was unfortunate that all requests to the verbose info were returning information about before or after the memory peek. The key thing here seems to be related to how sessionstore works and a high number of tabs (even if most are not active at that moment) I hope this helps.

That 180M aes.js compartments looks pretty suspicious either way.

Suspicious in what way?

Hum, I wonder if I should change the title of this bug. This is most noticeable while writing, but seems like it happens at any time it's just that it is most noticeable while editing a form. Anyway, the main cause still seems to be the many tabs + writing a form combo. The main issue is that I'm unable to get a memory "snapshot" while that happens because firefox becomes unresponsive.

Given that your session-restore files are so huge (the strings are hundreds of mb in attachment 751102 [details]), it seems quite likely that what's causing the jank is sessionrestore. We used to have bugs on sessionrestore being crappy when you have hundreds of tabs open. I don't recall if they got fixed, but they certainly weren't treated as a priority, so I don't want to get your hopes up here. You can reproduce this in safe-mode, right? What's the smallest number of tabs you can have open before this starts to affect you?

1st: Currently, sessionstore.js is 76.849.152 bytes long (~75 MB), so I don't understand why firefox requires 500MB to generate it and then store it. I also don't get why does firefox require more than 1 file handler at the same time for that file. Last time it lagged (while writing this) it was using 8 file handlers for the sessionstore.js... Why? "You can reproduce this in safe-mode, right?" Right. Even though firefox works more fluid, it still has about the same number of halting times and file handlers for sessionstore.js but it just does not use as much memory or take as long to come out of the lag (I just think that's just because it does not use as much memory). Everything else is the same. "What's the smallest number of tabs you can have open before this starts to affect you?" I don't know. I just know the ones I have currently:. I used this script: http://www.benjiegillam.com/2008/09/ever-wondered-how-many-firefox-tabs-you-have-open/ It says I have 330 tabs open. For the minimum value, I'll have to do some testing. I'll do that next week because I'm near overloaded this week.

I hear that sessionrestore is currently undergoing some major changes in bug 874381 and its blockers. It's possible that will improve the situation for you!

This way both are connected and it might be that with solving the other one this becomes automatically solved.

Session Restore might indeed take lots of RAM to produce a 75Mb file. That data: 0. sits somewhere in the UI; 1. is collected by Session Restore into a large object (copy #1); 2. then stringified (copy #2); 3. then encoded (copy #3); 4. then written. Until a few months ago, steps 1-4 were blocking. We have moved 4 off the main thread, hence removing the wait. Bug 838577 is all about making step 1 non-blocking, hence also removing the wait. We are also moving to get step 3. off the main thread, but that will take some time. Congratulations, by the way, you beat the record, our largest known session file was 60Mb :)

(In reply to brunoais from comment #16) > 1st: > Currently, sessionstore.js is 76.849.152 bytes long (~75 MB), so I don't > understand why firefox requires 500MB to generate it and then store it. > I also don't get why does firefox require more than 1 file handler at the > same time for that file. Last time it lagged (while writing this) it was > using 8 file handlers for the sessionstore.js... Why? What do you mean by "file handlers" and how did you find that number?

Hum... About those steps: Still... feels weired that it needs more than 300MB to do that... Maybe it's just how js objects exist in C++. I truly believe that they use much more memory than C++ objects, though. I checked that using the resource monitor, tab:Disk. Then I filtered by firefox.exe using the checkbox and then see the disk activity. Then I ordered by file name. Then it was just counting the numbers of lines that finished with sessionstore.js.tmp. Am I wrong with this?

I meant, 400MB, sorry.

I'll need to check.

Hi Bruno, could you double-check the number of file handles to sessionstore.js.tmp by using the following steps? http://www.sevenforums.com/tutorials/12531-resource-monitor-view-handles-modules.html Thanks

I'm unable to get any handlers using that, so I'll assume that this list of handlers I see is caused by the documented lag of the cleaningup of the information in the disk tab. It is opening writing and closing just fine. What it seems to be happening is that, sometimes, there are multiple sessionstore being executed at the same time. After some testing, including what you asked, I think I can conclude that the multiple file handler thingy is just an illusion caused by the amount of memory firefox sometimes uses and the lag of the data that appears at the "Disk" tab of resource monitor (it's something documented and experienced (I made a test about this using a php script and manipulating a file with exclusive lock).

1,756.96 MB (100.0%) -- explicit +----877.42 MB (49.94%) -- js-non-window ¦ +--847.67 MB (48.25%) -- compartments ¦ ¦ +--843.78 MB (48.03%) -- non-window-global ¦ ¦ ¦ +--439.71 MB (25.03%) -- compartment([System Principal], resource:///modules/sessionstore/_SessionFile.jsm) ¦ ¦ ¦ ¦ +--293.00 MB (16.68%) -- string-chars/huge ¦ ¦ ¦ ¦ ¦ +--146.50 MB (08.34%) -- string(length=76806229, "{"windows":[{"tabs":[{"entries"...") ¦ ¦ ¦ ¦ ¦ +--146.50 MB (08.34%) -- string(length=76806793, "{"windows":[{"tabs":[{"entries"...") ¦ ¦ ¦ ¦ +--146.56 MB (08.34%) -- objects-extra/elements ¦ ¦ ¦ ¦ +----0.14 MB (00.01%) ++ (3 tiny) ¦ ¦ ¦ +--308.16 MB (17.54%) -- compartment([System Principal], resource:///modules/sessionstore/SessionStore.jsm) ¦ ¦ ¦ ¦ +--273.33 MB (15.56%) -- string-chars ¦ ¦ ¦ ¦ ¦ +--192.17 MB (10.94%) -- huge ¦ ¦ ¦ ¦ ¦ ¦ +--146.50 MB (08.34%) -- string(length=76806793, "{"windows":[{"tabs":[{"entries"...") ¦ ¦ ¦ ¦ ¦ ¦ +---45.67 MB (02.60%) ++ (143 tiny) ¦ ¦ ¦ ¦ ¦ +---81.15 MB (04.62%) -- non-huge There are three 146.5 MiB strings in there. Two of them have length 76806793, and so there's a good chance they are identical; one belongs to _SessionFile.jsm and one to SessionStore.jsm. The third has length 76806229, so it's probably very similar to the other two. I wonder if some string copying is occurring that could be avoided. I also wonder if zones (bug 759585) would help -- it enabled sharing of strings between zones. brunoais, if you are able to try Firefox Beta (from beta.mozilla.org) which has zones in it, that might help.

Sorry for taking this long. But testing it was not that simple as I had to use firefox beta for a while as my day-to-day browser. By result is that firefox seem to be working more smoothly. It does not solve the issue completely, it still hangs, but it is now acceptably usable

We continue improving session restore. bruonais, are your hangs still present?

I have tweaked the options about sessionstore. I'll restore them to the values they were and I'll report back here about the results.

P.S. For some reason I didn't get the e-mail about this bug or I missed it

I've been unable to test this right because firefox is crashing (I've been sending the crash report every single time it happens) P.S. I found the e-mail.

I'm unable to do this test properly, by restoring the interval to the original value, my browser just keeps crashing after 1-2h after rebooting it from the crash (I'm sending about 8 crash reports per day). Any way of resolving these crashes and having firefox just using more memory than normal? It's kinda better than having it using nearly 2.5GB of memory most of the time and crashing crashing and crashing... What did you do that may be causing it actually using more memory than the amount it is supposed to be using? I mention that because the increase is quite crazy compared to firefox 24 (more than 500MB when not doing the sessionstore). I'll add example memory values as attachments

bruonais, can you post links to your crash reports? You can find them at url "about:crashes".

Here are today's: https://crash-stats.mozilla.com/report/index/07c47a1a-e47d-4eb3-a470-a82272131115 https://crash-stats.mozilla.com/report/index/07c4c1ec-5cdf-4dfc-8ee9-0a8332131115 https://crash-stats.mozilla.com/report/index/f77f0ac0-7d1d-45c5-9431-b92e82131115 https://crash-stats.mozilla.com/report/index/07c47a1a-e47d-4eb3-a470-a82272131115 https://crash-stats.mozilla.com/report/index/dc339da6-a249-41ef-873a-808f12131115 and yesterday's: https://crash-stats.mozilla.com/report/index/3087a22a-28ae-4f26-89f3-c74132131114 https://crash-stats.mozilla.com/report/index/8703ef80-ba11-46a4-b9f8-8a0f02131114 https://crash-stats.mozilla.com/report/index/b55cab46-0392-4663-89f7-94beb2131114 https://crash-stats.mozilla.com/report/index/3fd57868-3bd6-4a5e-acbf-392ba2131112 https://crash-stats.mozilla.com/report/index/0068e532-5ff1-47a4-83b8-cea5a2131115 https://crash-stats.mozilla.com/report/index/b55cab46-0392-4663-89f7-94beb2131114 I hope this helps

That looks like bug 767343 and bug 858791.

That's what the analyzer tool says.

I'm no longer having issues like this. Apparently this was caused by the sessionstore subsystem hanging with the sheer amount of data it had to work with. With that, I'll mark this as "solved"