Firefox gradually becomes more and more unresponsive during a session and then crashes when exiting
Well, my previous thread on this issue appears to have been deleted, and my ability to log in also until I reset my password - any explanation for this would be greatly appreciated.
However the basic problem remains as per the subject line.
The fundamental problem of responsiveness remains but the timeout crash has reduced in frequency since the last couple of upgrades.
Since the last crash I have been distracted by yet another firefox problem related to live bookmarks whereas Firefox, in it's wisdom, now seems to be changing the ID of the bookmarks thus breaking add-ins like brief that rely on the ID number being constant... sigh...
I just wonder if Mozilla is serious about Firefox anymore, for me they have made it almost a nightmare to use, every update seems to break something.
Where to go?
Επιπρόσθετες λεπτομέρειες συστήματος
- Shockwave Flash 18.0 r0
- Shockwave Flash 25.0 r0
- Πλατφόρμα χρήστη: Mozilla/5.0 (Windows NT 6.1; rv:53.0) Gecko/20100101 Firefox/53.0
How much RAM do you have ?
I suppose you are on a Windows 7 32bit OS ?
yep, isn't everyone? ;-)
Thanks will try the memory tools and report back
Yes when FF requested that I switch to HTML5 I dutifully obliged (responsiveness problem started about this time), however as many sites require Flash I found I had to reinstall it - I have recently disabled it again in case it had anything to do with it but not long enough yet to tell if it makes a difference - it shouldn't because the problem existed before reinstalling but we'll see.
I am the only user on this machine and have never signed into sync.
Trying to sign in it seems to have grabbed my gmail account and has sent a confirmation request - interesting. I have not confirmed.
The problem has been posted by people all over the place but there has never been a solution posted.
The problem certainly occurs in safe mode - one of the first things I tried.
I imagine 64bit OS are more common on desktop machines than are 32 bit OS.
I am not sure Firefox Sync is; or should be; able to just grab an email address. I hope that is not an indication that your System &/or email account has been hacked.
There are countless possible reasons for Firefox slowing down or having memory issues and with close on 1/2 billion users there are always going to be millions having some sort of issue with Firefox.
Well, I have tried everything now and the problem has become progressively worse (although the crashes have diminished).
It has got to the stage now whereby I can only play a few youtube videos before FF runs away. It's even worse if it's a video embedded elsewhere so it's not a YT thing.
I can only assume that FF is not a viable browser of a 32 bit system any more (at least with the other configurations I have).
It'll take a long while but I will begin to migrate to another browser and see how I go.
Thanks all who proffered suggestions they were very much appreciated even though they didn't lead to a solution.
you should have this degree of instability from firefox. therefore my opinion is that you are experiencing issues with your hardware.
if you suspect that there is an oddity at the 1 gigabyte mark, then look for things that may be limiting the memory to 1 gig, though you may have more.
one place to check is the virtual mem settings. open the pagefile/virtual memory panel and do a custom setting. set only 1 drive and use the recommended setting for both the min and the max. also, if you have 3 gigs, then the recommended setting by windows should equate to something like 5 gigs, being the formula is 1.5 times the size of your ram. if the recommended setting by windows cites less than 3 gigs, then it isnt seeing all of your ram.
the next step is to check the bios for your system. in some computers, the bios also manages the memory ram and the video that needs it too.
so if the bios doesnt see 3 gigs of ram, then the ram chips are bad. but if it does see the 3 gigs of ram, then double check the graphics settings and see if too much is allocated to use the ram. i dont think the graphics should use 2 gigs.
the next step is to check the boot configuration via windows. execute a msconfig command via run.
go to the boot tab then click on advance options. here you will see options to set the number of processors and the amount of ram to use. be sure to manually set both to their max levels.
next you can analyze the harddrive because if its flawed, then it will pose a problem for the system as well.
so do a check disk and defrag on the harddrive because if the pagefile is highly fragmented, then this can pose a problem for your system.
and if your partition is running low on room, this can cause havic as well.
Ok, after having done extensive testing and excluding other possible issues as mentioned above, I think I can definitely confirm this to be a very reproducible bug in FFs memory management system. I think that this has in fact been conceded by Mozilla with their recent introduction of a new signature for this problem (OOM | small).
Since the problem always occurs at around the same memory allocation level (1GB) I would be surprised if it isn't a simple numerical out of bounds error in their chunk management system.
There are two symptoms (at least) of this problem, the first being a crash returning the above mentioned signature, and the other being a wait on thread access which is never honoured. This latter issue has the rather peculiar result of FF using exactly 50% of the CPU resource, this may have been somehow hand crafted, or indicative of the image using only one of the two processors (thinking about it the latter makes some sense), never the less that is a rather interesting phenomenon.
This problem would probably be resolved (or rather worked around) if my version of FF could make use of Electrolysis (assuming each process has it's own memory management system), however, whilst the majority of my add-ons remain "legacy" that's not possible without regressing FF to 5% of it's potential.
(It would seem that few add-on providers will port to web extensions, even if possible, until they absolutely have to.)
you're analysis is very interesting. but my assessment is that what you are experiencing on your system with FF is not the norm occurring on the majority of systems.
to this end, were you able to run FF in a windows environment with no other windows installed?
in other words, do you have a virgin windows installation for testing purposes and then ran FF in it to see how it behaves in this pure environment, per se?
something to keep in mind is that FF may have actually joined the ban wagon and may be aggregating information on you, just like other companies are doing at this time including microsoft via win10, adobe, at&t, free anti-virus programs, etc...
you're analysis is very interesting. but my assessment is that what you are experiencing on your system with FF is not the norm occurring on the majority of systems. to this end, were you able to run FF in a windows environment with no other windows installed? in other words, do you have a virgin windows installation for testing purposes and then ran FF in it to see how it behaves in this pure environment, per se? something to keep in mind is that FF may have actually joined the ban wagon and may be aggregating information on you, just like other companies are doing at this time including microsoft via win10, adobe, at&t, free anti-virus programs, etc...
No, the problem is fairly wide spread, there are a great number of reports of similar behaiour if you google FF responds slowly and then crashes. There is never a solution so I can only assume people either put up with the problem or move to another browser.
The issue is easily reproducible, I have done so on at least 4 machines. All you have to do is arrange for FF to run out of RAM memory, ie, get swapped out to virtual (disk) memory and before long it will exhibit the issue.
The problem appears to be related to the fact that FF doesn't relinquish memory assigned to non active tabs. That in itself is not a problem but it then gets in a thread loop that a) chews up CPU, and b) prevents FF from exiting cleanly. This, to me, implies a performance optimisation bug.
The fact that FF then runs at 50% of CPU resource is also indicative at some kind of CPU/Memory performance optimisation technique that has gone wrong.
I should also note that I have no other application issues even when artificially reserving all available RAM memory.