Closed Bug 711900 Opened 13 years ago Closed 13 years ago

Make Firefox 10 not have more GC/CC related hangs than Firefox 9

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox9 --- unaffected
firefox10 + fixed
firefox11 + fixed

People

(Reporter: bzbarsky, Unassigned)

References

Details

(Whiteboard: [qa-])

Attachments

(2 files)

Patch to add more GC/CC reason info to error console
(deleted), patch
Details | Diff | Splinter Review
disable background arena allocation on aurora/beta
(deleted), patch
billm
: review+
akeybl
: approval-mozilla-aurora+
akeybl
: approval-mozilla-beta+
Details | Diff | Splinter Review 
This is a tracking bug resolving the hang issues I and others have been seeing.  This certainly depends on bug 707162, but it's not clear whether that's all there is to it...
Boris, you did have more CC/GC hangs on 10 than on 9 even before strong parent node was
backed out from 9, right?

Anyway, I'll re-upload strong parent node backout from 10 to tryserver.
(Patches are in Bug 682420)
> Boris, you did have more CC/GC hangs on 10 than on 9 even before strong parent node was
> backed out from 9, right?

Yes.
This patch adds some more reason info about CCs and GCs to the error console. Note that the GC part is especially hacky. But it might be useful for understanding why we're GCing so often.
I have a similar patch in bug 706227.  I also have a slightly less gross version that uses enums, but I haven't uploaded it yet.
Depends on: 707834
Depends on: 706227
bz, we suspect that your regression might have been caused by the landing of bug 688641. That bug landed on Oct 7, although I believe it was in time for that build. Could you test nightlies, say Oct 6 vs. Oct 8, to see if it came in around that time?
Just started browsing in an Oct 8 build.  I'll do that for three days, then try an Oct 6 build....
OK, an Oct 8 build does seem to show the problem:

GC mode: full, timestamp: 1324826593441414, duration: 1992 ms.
CC timestamp: 1324826599802528, collected: 412 (412 waiting for GC), suspected: 1268, duration: 1357 ms.
 ----------
GC mode: full, timestamp: 1324826605846495, duration: 2041 ms.
CC timestamp: 1324826611384846, collected: 959 (959 waiting for GC), suspected: 1761, duration: 536 ms.
 ----------
GC mode: full, timestamp: 1324826616692099, duration: 1304 ms.
CC timestamp: 1324826622256503, collected: 175 (175 waiting for GC), suspected: 533, duration: 561 ms.
 ----------
CC timestamp: 1324826636293161, collected: 72 (247 waiting for GC), suspected: 1217, duration: 599 ms.
 ----------
GC mode: full, timestamp: 1324826643366418, duration: 2375 ms.
CC timestamp: 1324826644206000, collected: 1876 (1876 waiting for GC), suspected: 2714, duration: 622 ms.
 ----------
GC mode: full, timestamp: 1324826650086842, duration: 1878 ms.
CC timestamp: 1324826650844843, collected: 438 (438 waiting for GC), suspected: 5990, duration: 593 ms.
 ----------
GC mode: full, timestamp: 1324826656243798, duration: 1403 ms.
CC timestamp: 1324826662595883, collected: 190 (190 waiting for GC), suspected: 1442, duration: 1349 ms.
 ----------
GC mode: full, timestamp: 1324826669669347, duration: 2846 ms.
CC timestamp: 1324826670646426, collected: 14952 (14952 waiting for GC), suspected: 9374, duration: 641 ms.
 ----------
GC mode: full, timestamp: 1324826675620334, duration: 1052 ms.
CC timestamp: 1324826680105666, collected: 196 (196 waiting for GC), suspected: 1621, duration: 552 ms.
 ----------
CC timestamp: 1324826694092025, collected: 677 (873 waiting for GC), suspected: 2437, duration: 555 ms.
GC mode: full, timestamp: 1324826700296868, duration: 2208 ms.

Going to try Oct 6 next.
There may be another report of this in bug 696761.
Depends on: 696761
There's some data that could be useful in bug 608954.
Blocks: 694243
OK, I do think the Oct 6 build is better.  I'm still getting pauses, but they're not nearly as frequent as they were in the Oct 8 build.  It's pretty common for me to go a minute or more without a GC.
The patch is for aurora and beta to disables the background chunk allocation. The changes from the bug 713916 and its dependent bugs are too risky for those branches.
Assignee: nobody → igor
Attachment #584961 - Flags: review?(wmccloskey)
Attachment #584961 - Flags: review?(wmccloskey) → review+
Comment on attachment 584961 [details] [diff] [review]
disable background arena allocation on aurora/beta

[Approval Request Comment]
Regression caused by (bug #): bug 688641
User impact if declined: 
Pauses up to several seconds due to excessive garbage collection that repeats each 5seconds

Testing completed (on m-c, etc.): 
The patch disables the optimization from the bug 688641 effectively reverting those changes. It was not tested on m-c as there a proper fix is provided but it is too risky. Any beta or aurora tester on a single core system should have seen the effect f this patch.

Risk to taking this patch (and alternatives if risky): The risk should be low as the patch revert the GC allocation code to the state it was before the bug 688641 has landed.
Attachment #584961 - Flags: approval-mozilla-beta?
Attachment #584961 - Flags: approval-mozilla-aurora?
(In reply to Igor Bukanov from comment #14)
> 
> Testing completed (on m-c, etc.): 
> The patch disables the optimization from the bug 688641 effectively
> reverting those changes. It was not tested on m-c as there a proper fix is
> provided but it is too risky. Any beta or aurora tester on a single core
> system should have seen the effect f this patch.
> 
> Risk to taking this patch (and alternatives if risky): The risk should be
> low as the patch revert the GC allocation code to the state it was before
> the bug 688641 has landed.

For what its worth, I have been testing this patch based on a *beta* try build for a bit more than a week, and I have noticed markedly better CC times (when coupled with the addition of http://hg.mozilla.org/releases/mozilla-beta/rev/52aad9bbe2ff which was also in the try build)

Its still not perfect, but much much better than it was in beta 1. I have noticed no breakages in my single-user testing of this build.
(In reply to Justin Wood (:Callek) from comment #15)
bah ignore this -- I was in the wrong bug
(In reply to Igor Bukanov from comment #14)
> Comment on attachment 584961 [details] [diff] [review]
> disable background arena allocation on aurora/beta

Igor - if nightlies are also affected by the same GC/CC hangs (which is the current thinking) we should land this everywhere. In that case, let's land and bake on 12 before taking on 11/10.
(In reply to Alex Keybl [:akeybl] from comment #17)
> Igor - if nightlies are also affected by the same GC/CC hangs (which is the
> current thinking)

Hm, I suppose this should not be the case - the bug 713916 should address it. But changes in that bug are too risky for 11/10.
Comment on attachment 584961 [details] [diff] [review]
disable background arena allocation on aurora/beta

[Triage Comment]
Let's land on Aurora/Beta since Igor let us know that bug 713916 will cover the m-c case.
Attachment #584961 - Flags: approval-mozilla-beta?
Attachment #584961 - Flags: approval-mozilla-beta+
Attachment #584961 - Flags: approval-mozilla-aurora?
Attachment #584961 - Flags: approval-mozilla-aurora+
I ran some comparison tests with some different builds.  
Test case:
Fresh profile, navigate to lights.elliegoulding.com and click play
watch error console
after playing for a minute or so, take a sample of the GC and CC times in the log.
Margin of error, I expect, is about 5 or 6 ms either way.  This is just a sampling, not an average:

FF 9.01:
CC timestamp: 1326393260764664, collected: 0 (0 waiting for GC), suspected: 100, duration: 4 ms.
GC mode: full, timestamp: 1326393265308198, duration: 39 ms.
* 4-5 sec between GC

FF10 Oct/8:
CC timestamp: 1326393572664655, collected: 0 (0 waiting for GC), suspected: 89, duration: 8 ms.
GC mode: full, timestamp: 1326393571720369, duration: 64 ms.
* 4 sec between GC

FF10 on Beta: 
CC timestamp: 1326392757764336, collected: 21 (21 waiting for GC), suspected: 65, duration: 11 ms.
GC mode: full, timestamp: 1326392756794096, duration: 55 ms.
* 5 sec between GC

FF12 on Nightly:
CC(T+181.9) collected: 18 (18 waiting for GC), suspected: 118, duration: 16 ms.
GC(T+185.8) Type:Glob, Total:55.7, Wait:0.1, Mark:43.4, Sweep:12.2, FinObj:5.2, FinStr:0.1, FinScr:0.1, FinShp:0.9, DisCod:1.2, DisAnl:3.0, XPCnct:0.8, Destry:0.0, End:0.8, +Chu:0, -Chu:1, Reason:Mallc
* 4 sec between GC
I have noticed that using http://mcdustsucker.blogspot.com/ with a clean profile starts growing when I scroll. I installed memchaser [1] and this is one the figures it was getting from the error console. 

Memory: 338MB, GC: 81.2ms, CC: 164ms

I am only visiting that site with the profile and it makes memory jumps. I am seeing the same issue in Release, Beta, Aurora, and Nightly.

The site has a lot so havent narrowed the cause down

[1] https://github.com/whimboo/memchaser
This morning I have started with about 500MB after waking up my computer from sleep. Through the day I was mainly working on Bugzilla, Github, and crash-stats. Now I have those values with Aurora:

Memory: 1092MB, GC: 144.2ms, CC: 383ms

525.16 MB (49.14%) -- heap-unclassified

I don't have multiple windows, only a couple of tabs loaded - not more than this morning. But as it looks like the memory doesn't get released properly and at the same time the GC/CC durations stay always that high and make Firefox unresponsive in regular intervals.
Henrik, if you could send me a cycle collector log that could be useful in letting me figure out what is leaking.  Thanks!  (instructions here: https://wiki.mozilla.org/Performance:Leak_Tools#Cycle_collector_heap_dump )
I did some analysis of blassey's and CWW's slow CC logs in bug 717500.  For Blassey's log, about 200,000 of his 740,000 JS objects in the CC graph were being held by live DOM.  That's a fair chunk, but not enough to explain it all.  For CWW, only 18,000 out of 700,000 nodes were so held, so it doesn't explain it at all.

My next step is to try collapsing strongly connected components in the graph and see if the resulting shrunk graph is even vaguely comprehensible to see if I can visually identifying where these huge chunks of JS are living.
Hi all. I'm having hang issues with my Firefox (Fx10 beta), and Laura Mesa suggested I add myself here...if you need another Firefox profile to investigate and debug I'm happy to help.
Hi, thanks for the report.  Probably the easiest way to see if these are GC or CCs is to download the memchaser addon from this URL: https://github.com/whimboo/memchaser/downloads then install the addon from the file.  This will place a little bar at the bottom of your browser window that gives the GC and CC times.  If either of those are above, say, 700ms, you are having some kind of GC/CC problems.
Following up from comment #27, I installed the memchaser add-on and am noticing that my GC and/or CC time is very frequently above 700ms (especially the longer I have Firefox running).

So, let me know if there's anything my Firefox profile or I can do to help.
I've been having similar issues on FF10 OSX 10.7. I've installed the memchaser addon, and while I'm not seeing times of 700ms, it usually hovers around GC: 75ms, CC 100ms. Every few seconds the browser completely locks up for about a second, including when I'm doing something as simple as typing this report. I have about 11 tabs open, and have tried restarting FF multiple times.

The pausing, over a period of 60 seconds, happens about 12 times, and pauses for about 1 second each time.

I've tried submitting a cycle collector log, but each time I try to run the snippet in the error console (tried twice now), FF immediately hard crashes, and the bug reporter comes up.

If there is anything I can do to help, please let me know.
Thanks for the report, Andrew!  Are you saying that your GC/CC times are usually around 75ms/100ms, but sometimes they are much higher?  Or they are always that low?  If they are always that low, and don't correspond to MemChaser showing a high number (500ms or more), then it sounds like you have another issue besides the GC or CC.

I'm not sure why the cycle collector dump would be crashing.  If you go into about crashes, could you paste the links to the crash reports around the time you think you did the CC dump?  I could look into that.
Sometimes they are much higher, but on average are as reported. For example, just a second ago, GC was at 104ms and CC was just at 201ms. GC has been "red" (> 100ms) for about an hour now, and CC frequently goes red every few minutes.

Here is the crash report from my attempt: https://crash-stats.mozilla.com/report/index/bp-f7d89541-cd71-4265-b06c-8ea902120130

If the problem is not related to GC or CC, is there something I can do to try and narrow down the issue? If I recorded my UI right now, you'd think the video was skipping, it's that bad.
Yeah, the "red" highlighting is not really tuned very well. :)  "Normal" times for the GC are around 250ms, and CC is around 200ms.  That's about a quarter of a second each, so it should only show up as slight hitching while scrolling or typing, not your whole browsing hanging for a long period.

That crash is really odd.  Somehow it is crashing during a QI.  I have no idea why that might happen.

Sorry, I'm not really sure what you can do.  You should probably file a new bug for your issue, and put a link to it here.  There are various things you can try, like disabling hardware acceleration, trying safe mode, etc.
After fooling around with Safe Mode and manually disabling each of my addons, I've discovered that my problem (the constant, second-long stutter) was caused by Visual Hashing v0.2. I'm not sure what changed that would have caused such a drastic change in performance (I've been running with that enabled since it was released), but my FF is now snappy as ever.

I'll be sending some feedback to try and get this fixed.
Thanks for the followup!  I'm glad you were able to figure that out.
i'm also having the same issues while typing/scrolling esp. on g+, myspace and facebook. i also have the same problem when i go to shutdown ff for the night. ff is also slow to boot first thing in the morning with hangs as well - all other programs/browsers boot fine. i'm using ff ver 9 with ms vista - serv. pack 2 on a dell latitude D520. i have at least 25% of free space on my HD at all times. any poss. of RAM issues - is there a plain english fix?

not to change the subject too much, is real player ever going to work with ff?

thanks.

goth1856@yahoo.com
This bug is about people having trouble in Firefox 10 who didn't have problems in Firefox 9, not people who are having trouble in Firefox 9.  Try safe mode, in case it is an addon.  Try looking around on http://support.mozilla.org/ to see if you can find some help there.
(In reply to Andrew McCreight [:mccr8] from comment #36)
> This bug is about people having trouble in Firefox 10 who didn't have
> problems in Firefox 9, not people who are having trouble in Firefox 9.  Try
> safe mode, in case it is an addon.  Try looking around on
> http://support.mozilla.org/ to see if you can find some help there.

this hang/freeze issue has been going on since ff ver.3  o.O

tired of the buck being passed. :-(
like goth1856 I have had this issue for a long time, at least since ff3.6.

So I just discovered this addon and am currently using ff9, want my figures?

Resident 1004MB
GC 901ms (6.0s)
CC 769ms (5.1s)

obviously these are fluctuating, they are sometimes lower but also sometimes higher.  What is the number in brackets for?

Give em a firefox that does no GC perhaps it will run like a proper browser then :)
for what its worth GC drops fairly regularly to about 200ms, but CC is high almost all the time above 700ms.
Please file new bugs for these issues and CC me.

The time in parentheses is the time since the last GC or CC.
the bug is still there in ver 10. :-(
This bug is for people who are having problems with 10 who did not have problems with 9.  It sounds like you have been having a problem with hangs and pauses for longer than that, so it is probably a separate issue, and so should have a separate bug.  Thanks.
(In reply to Andrew McCreight [:mccr8] from comment #42)
Andrew, I am sorry to say that it seems we are looking at the same problems persisting or at least issues that are mimicking each other pretty darn closely. The hanging, freezing, taking time and all the bootstraps and compartments taking up HUGE memory on a fresh startup just seems a bit absurd. It has been like this with Fx for a LONG time and I am going as far back as the late 3.x which was reasonable but not good to the early 4.x branch and on where things just got BAD. Fx performance is just ****, I wish I could use a more professionally less offensive term, but that was as close as I could find.

Don't get me wrong, great strides have been made and the MemShrink team has done good things but the fact is that the fluctuations on a clean start looking at the about:memory?verbose clearly shows that we got issues that are not gone and in some cases seem unpredictably worse in some areas while slightly better in others. Not just trying to criticize without providing a solution, but I think its important for you guys to know why people are complaining and feeling that Fx is pretty much sliding down its high standing and losing ground FAST. It got bloated, too many band-aid fixes and not enough proper benchmarking, as evident by the rapid versioning we are seeing, which is NEVER a good sign, no matter how we try to justify it.

Anyway, just saying. If anyone opens a new issue/bug can you please CC me on it so I can keep in touch with any issue and progress as I do support many different addons and code, would like to know where we are. Appreciate it and thank you in advance.
(In reply to GµårÐïåñ from comment #43)
> (In reply to Andrew McCreight [:mccr8] from comment #42)
> Andrew, I am sorry to say that it seems we are looking at the same problems
> persisting or at least issues that are mimicking each other pretty darn
> closely. The hanging, freezing, taking time and all the bootstraps and
> compartments taking up HUGE memory on a fresh startup just seems a bit
> absurd. It has been like this with Fx for a LONG time and I am going as far
> back as the late 3.x which was reasonable but not good to the early 4.x
> branch and on where things just got BAD. Fx performance is just ****, I wish
> I could use a more professionally less offensive term, but that was as close
> as I could find.
> 
> Don't get me wrong, great strides have been made and the MemShrink team has
> done good things but the fact is that the fluctuations on a clean start
> looking at the about:memory?verbose clearly shows that we got issues that
> are not gone and in some cases seem unpredictably worse in some areas while
> slightly better in others. Not just trying to criticize without providing a
> solution, but I think its important for you guys to know why people are
> complaining and feeling that Fx is pretty much sliding down its high
> standing and losing ground FAST. It got bloated, too many band-aid fixes and
> not enough proper benchmarking, as evident by the rapid versioning we are
> seeing, which is NEVER a good sign, no matter how we try to justify it.
> 
> Anyway, just saying. If anyone opens a new issue/bug can you please CC me on
> it so I can keep in touch with any issue and progress as I do support many
> different addons and code, would like to know where we are. Appreciate it
> and thank you in advance.

My sentiments exactly.  EXACTLY.

At first, I thought I was imagining this behaviour, given that FF had performed admirably (for me), in light of the complexity of its ever-evolving nature.

I had not experienced the freezing/erratic behaviour on FF prior to 'upgrading' to v9 (and now, v10).  I suspected a plu-in might have been to blame, but uninstalling the few plug-ins I started using recently did not resolve the problem.  FF has become unusable.  Sure, it loads the few tabs I had when I closed it, but should I desire to visit some sites (like Facebook), or open another tab, or click on the a link, FF wildly consumes memory as time passes, untilmately become useless in a short while.

FF is the ONLY browser I had used since around v3.x.  I love the few extensions I use (like UnMHT), but this 'bug' is inexcusable.  This bug should be the sole concern at this moment, given its effect on the usability of the browser.

I do not like IE, nor am I warming up to Chrome (I've installed it, but I have yet to use it).  For me, this leaves Opera as the browser to go to (the browser I last used before switching to FF).  I configure systems for family, friends, and the occasional customer desiring a new build or reinstall of their OS and the basic necessities.  In light of the severity of this bug, I will be switching all of their browsers to Opera.

Please fix this issue ASAP.  I cannot recommend FF again until this issue is completely eradicated.  I'm certain many people share that sentiment, some of whom will never bother to use FF again.
Ivan, want to try Nightly (http://nightly.mozilla.org/) and report whether that helps with
the issues you see ?
Hi GµårÐïåñ and Ivan Azymov,

I'm sorry you are experiencing such extreme problems.  If each of you would please file new bugs and CC me and I would be happy to help you figure out what exactly is going wrong with your browsers.  There are a wide variety of possible causes besides garbage collector or cycle collector problems, from addons to broken graphics drivers.  For instance, a recent version of McAfee Site Advisor causes some extreme memory problems for people.  Some people also end up with profiles that are in a damaged state that can cause problems.  Thanks.
(In reply to Olli Pettay [:smaug] from comment #45)
> Ivan, want to try Nightly (http://nightly.mozilla.org/) and report whether
> that helps with
> the issues you see ?

I installed the Nightly about an hour ago--no change.
(In reply to Andrew McCreight [:mccr8] from comment #46)
> Hi GµårÐïåñ and Ivan Azymov,
> 
> I'm sorry you are experiencing such extreme problems.  If each of you would
> please file new bugs and CC me and I would be happy to help you figure out
> what exactly is going wrong with your browsers.  There are a wide variety of
> possible causes besides garbage collector or cycle collector problems, from
> addons to broken graphics drivers.  For instance, a recent version of McAfee
> Site Advisor causes some extreme memory problems for people.  Some people
> also end up with profiles that are in a damaged state that can cause
> problems.  Thanks.

I installed the Nightly about an hour ago--no change.

I am using a new installation of WINDOWS 7 (64-bit), w/ no anti-virus.  It is a new installation.  In additional to ZoneAlarm Pro, I have WriteMonkey, GimPad, VueScan, and GoodSync, ImgBurn, AnyDVD HD, DiskAid, iTunes (installed because of DiskAid requirement), FoxIt Reader, and Better File Rename, and Norton Ghost.  No other apps installed.  All WINDOWS 7 updates installed.  No driver conflicts.

These are all apps I have used in the past, for quite some time.  I would find it surprising that any of them would be causing such a problem.

In light of this problem, WINDOWS 7 (64-bit) is terribly bloated.  Sure, it works fine, but 20GB?  CrunchBang! linux beckons.  I may finally take the time to venture into that world.

I would appreciate a browser not far from Dillo--the absolute bare necessities--so long as it worked properly, all of the time.  (And, yes, AdBlock is one of those bare necessities.)

I've installed and tried Opera, Slepnir, Maxthon, and a couple of others during the past 24HRS, and can say without reservation that aside from this vexing problem with Firefox, they all fall terribly short to the usability of Firefox.

I assume crack addiction must be like this.  Damn you for making me care for Firefox.  DAMN YOU ALL TO HELL!  (Okay, a bit over the top.  But, I'll be keeping my ears and eyes open for a Firefox version without this crippling flaw.)
(In reply to Olli Pettay [:smaug] from comment #45)
> Ivan, want to try Nightly (http://nightly.mozilla.org/) and report whether
> that helps with
> the issues you see ?

I have the following Add-Ons installed:

Adblock Plus 2.0.3
Adblock Plus Pop-Up Addon 0.3
BetterPrivacy 1.68
DownloadHelper 4.9.8
Easy YouTube Video Downloader 5.9
It's All Text! 1.6.3
Mozilla Archive Format 2.0.4
TinEye Reverse Image Search 1.1
UnMHT 5.7.0
Youtube Video Replay 1.2

I suspected that one or more of the plug-ins could be causing the problem (or exacerbating it, if it is indeed a problem within the browser itself).

I had uninstalled two previous Add-Ons about three days ago, the name of which I cannot remember.  But the problem persisted.

However, I restarted FF and uninstalled the Add-On, 'FireShort 0.96'.  That was about 25 minutes ago.  The memory usage is steadily swelling, but prior to uninstalling this Add-On, FF would have 'frozen' well in advance of 25 minutes.

Yeah.  It's definitely climbing to 'freezing' point now.  Nevertheless, uninstalling this plug-in delayed the time significantly.

Perhaps this help you.
(In reply to Ivan Azymov from comment #48)
> (In reply to Andrew McCreight [:mccr8] from comment #46)
> > Hi GµårÐïåñ and Ivan Azymov,
> > 
> > I'm sorry you are experiencing such extreme problems.  If each of you would
> > please file new bugs and CC me and I would be happy to help you figure out
> > what exactly is going wrong with your browsers.  There are a wide variety of
> > possible causes besides garbage collector or cycle collector problems, from
> > addons to broken graphics drivers.  For instance, a recent version of McAfee
> > Site Advisor causes some extreme memory problems for people.  Some people
> > also end up with profiles that are in a damaged state that can cause
> > problems.  Thanks.
> 
> I installed the Nightly about an hour ago--no change.
> 
> I am using a new installation of WINDOWS 7 (64-bit), w/ no anti-virus.  It
> is a new installation.  In additional to ZoneAlarm Pro, I have WriteMonkey,
> GimPad, VueScan, and GoodSync, ImgBurn, AnyDVD HD, DiskAid, iTunes
> (installed because of DiskAid requirement), FoxIt Reader, and Better File
> Rename, and Norton Ghost.  No other apps installed.  All WINDOWS 7 updates
> installed.  No driver conflicts.
> 
> These are all apps I have used in the past, for quite some time.  I would
> find it surprising that any of them would be causing such a problem.
> 
> In light of this problem, WINDOWS 7 (64-bit) is terribly bloated.  Sure, it
> works fine, but 20GB?  CrunchBang! linux beckons.  I may finally take the
> time to venture into that world.
> 
> I would appreciate a browser not far from Dillo--the absolute bare
> necessities--so long as it worked properly, all of the time.  (And, yes,
> AdBlock is one of those bare necessities.)
> 
> I've installed and tried Opera, Slepnir, Maxthon, and a couple of others
> during the past 24HRS, and can say without reservation that aside from this
> vexing problem with Firefox, they all fall terribly short to the usability
> of Firefox.
> 
> I assume crack addiction must be like this.  Damn you for making me care for
> Firefox.  DAMN YOU ALL TO HELL!  (Okay, a bit over the top.  But, I'll be
> keeping my ears and eyes open for a Firefox version without this crippling
> flaw.)


I have the following Add-Ons installed:

Adblock Plus 2.0.3
Adblock Plus Pop-Up Addon 0.3
BetterPrivacy 1.68
DownloadHelper 4.9.8
Easy YouTube Video Downloader 5.9
It's All Text! 1.6.3
Mozilla Archive Format 2.0.4
TinEye Reverse Image Search 1.1
UnMHT 5.7.0
Youtube Video Replay 1.2

I suspected that one or more of the plug-ins could be causing the problem (or exacerbating it, if it is indeed a problem within the browser itself).

I had uninstalled two previous Add-Ons about three days ago, the name of which I cannot remember.  But the problem persisted.

However, I restarted FF and uninstalled the Add-On, 'FireShort 0.96'.  That was about 25 minutes ago.  The memory usage is steadily swelling, but prior to uninstalling this Add-On, FF would have 'frozen' well in advance of 25 minutes.

Yeah.  It's definitely climbing to 'freezing' point now.  Nevertheless, uninstalling this plug-in delayed the time significantly.

Perhaps this help you.
(In reply to Ivan Azymov from comment #47)
> (In reply to Olli Pettay [:smaug] from comment #45)
> > Ivan, want to try Nightly (http://nightly.mozilla.org/) and report whether
> > that helps with
> > the issues you see ?
> 
> I installed the Nightly about an hour ago--no change.

(In reply to Olli Pettay [:smaug] from comment #45)
> Ivan, want to try Nightly (http://nightly.mozilla.org/) and report whether
> that helps with
> the issues you see ?

I have uninstalled the Add-On, 'It's All Text! 1.6.3'.  The wild fluctuations in memory (say 300MB to 800MB, and then back) are no longer seen.  However, the browser did ultimately 'freeze', but after 32 minutes of constant use (previously, half that time proved the limit).

I've just also uninstalled the Add-On, 'TinEye Reverse Image Search 1.1', though in monitoring memory usage, that has not affected the performance of FF in a positive or negative manner.

Obviously, uninstalling Add-Ons has not fixed the problem, but it did eliminate the erratic behaviour of memory usage.

The Add-Ons remaining in my installation are:

Adblock Plus 2.0.3
Adblock Plus Pop-Up Addon 0.3
BetterPrivacy 1.68
DownloadHelper 4.9.8
Easy YouTube Video Downloader 5.9
Mozilla Archive Format 2.0.4
UnMHT 5.7.0
Youtube Video Replay 1.2

And this concludes my mystical approach in attempting to find a solution to the problem.
(In reply to Andrew McCreight [:mccr8] from comment #46)
> Hi GµårÐïåñ and Ivan Azymov,
> 
> I'm sorry you are experiencing such extreme problems.  If each of you would
> please file new bugs and CC me and I would be happy to help you figure out
> what exactly is going wrong with your browsers.  There are a wide variety of
> possible causes besides garbage collector or cycle collector problems, from
> addons to broken graphics drivers.  For instance, a recent version of McAfee
> Site Advisor causes some extreme memory problems for people.  Some people
> also end up with profiles that are in a damaged state that can cause
> problems.  Thanks.

I have uninstalled the Add-On, 'It's All Text! 1.6.3'.  The wild fluctuations in memory (say 300MB to 800MB, and then back) are no longer seen.  However, the browser did ultimately 'freeze', but after 32 minutes of constant use (previously, half that time proved the limit).

I've just also uninstalled the Add-On, 'TinEye Reverse Image Search 1.1', though in monitoring memory usage, that has not affected the performance of FF in a positive or negative manner.

Obviously, uninstalling Add-Ons has not fixed the problem, but it did eliminate the erratic behaviour of memory usage.

The Add-Ons remaining in my installation are:

Adblock Plus 2.0.3
Adblock Plus Pop-Up Addon 0.3
BetterPrivacy 1.68
DownloadHelper 4.9.8
Easy YouTube Video Downloader 5.9
Mozilla Archive Format 2.0.4
UnMHT 5.7.0
Youtube Video Replay 1.2

And this concludes my mystical approach in attempting to find a solution to the problem.
(In reply to Olli Pettay [:smaug] from comment #45)
> Ivan, want to try Nightly (http://nightly.mozilla.org/) and report whether
> that helps with
> the issues you see ?

Illogical.  The problem has been eradicated.

After uninstalling the Add-On, 'TinEye Reverse Image Search 1.1'@0237HRS, I restarted FF.  I am using FB, and I've viewed several videos on YouTube, and tabs open total 14.  AND, FF continues to function properly, 1Hr 52 minutes later.  (It's almost 0430HRS now.)

This all proves once again that part of dealing with software problems (until resolve in a more technical manner), is still alchemy and black magic.

I hope this empirical approach to solving this issue could help you in finding out why FF otherwise fails to function.

This is a list of the Add-Ons I was able to keep with FF functioning properly:

Adblock Plus 2.0.3
Adblock Plus Pop-Up Addon 0.3
BetterPrivacy 1.68
DownloadHelper 4.9.8
Easy YouTube Video Downloader 5.9
Mozilla Archive Format 2.0.4
UnMHT 5.7.0
Youtube Video Replay 1.2
(In reply to Andrew McCreight [:mccr8] from comment #46)
> Hi GµårÐïåñ and Ivan Azymov,
> 
> I'm sorry you are experiencing such extreme problems.  If each of you would
> please file new bugs and CC me and I would be happy to help you figure out
> what exactly is going wrong with your browsers.  There are a wide variety of
> possible causes besides garbage collector or cycle collector problems, from
> addons to broken graphics drivers.  For instance, a recent version of McAfee
> Site Advisor causes some extreme memory problems for people.  Some people
> also end up with profiles that are in a damaged state that can cause
> problems.  Thanks.

Illogical.  The problem has been eradicated.

After uninstalling the Add-On, 'TinEye Reverse Image Search 1.1'@0237HRS, I restarted FF.  I am using FB, and I've viewed several videos on YouTube, and tabs open total 14.  AND, FF continues to function properly, 1Hr 52 minutes later.  (It's almost 0430HRS now.)

This all proves once again that part of dealing with software problems (until resolve in a more technical manner), is still alchemy and black magic.

I hope this empirical approach to solving this issue could help you in finding out why FF otherwise fails to function.

This is a list of the Add-Ons I was able to keep with FF functioning properly:

Adblock Plus 2.0.3
Adblock Plus Pop-Up Addon 0.3
BetterPrivacy 1.68
DownloadHelper 4.9.8
Easy YouTube Video Downloader 5.9
Mozilla Archive Format 2.0.4
UnMHT 5.7.0
Youtube Video Replay 1.2
(In reply to Ivan Azymov from comment #54)
> After uninstalling the Add-On, 'TinEye Reverse Image Search 1.1'@0237HRS, I
> restarted FF.  I am using FB, and I've viewed several videos on YouTube, and
> tabs open total 14.  AND, FF continues to function properly, 1Hr 52 minutes
> later.  (It's almost 0430HRS now.)
> 
> This all proves once again that part of dealing with software problems
> (until resolve in a more technical manner), is still alchemy and black magic.
> 
> I hope this empirical approach to solving this issue could help you in
> finding out why FF otherwise fails to function.

Yes, that is very helpful!  Thanks for investigating.  Olli and I can look into whether that addon is doing something bad, or if we could make the cycle collector better somehow to deal with it.  Or both.

It really isn't that illogical.  It is really great that Firefox addons can do all sorts of crazy stuff, but the flip side of that is that they can cause immense problems, and unfortunately right now it is really hard to tell what is to blame.  But anyways, a general lesson here is that if your Firefox is behaving horribly badly then try disabling your addons.  Hopefully in the future we'll be able to provide more useful feedback to users about which addons may be negatively impacting them.

So, to summarize, these addons were causing some amount of trouble?
  FireShort 0.96
  It's All Text! 1.6.3
  TinEye Reverse Image Search 1.1
(In reply to Andrew McCreight [:mccr8] from comment #55)
> (In reply to Ivan Azymov from comment #54)
> > After uninstalling the Add-On, 'TinEye Reverse Image Search 1.1'@0237HRS, I
> > restarted FF.  I am using FB, and I've viewed several videos on YouTube, and
> > tabs open total 14.  AND, FF continues to function properly, 1Hr 52 minutes
> > later.  (It's almost 0430HRS now.)
> > 
> > This all proves once again that part of dealing with software problems
> > (until resolve in a more technical manner), is still alchemy and black magic.
> > 
> > I hope this empirical approach to solving this issue could help you in
> > finding out why FF otherwise fails to function.
> 
> Yes, that is very helpful!  Thanks for investigating.  Olli and I can look
> into whether that addon is doing something bad, or if we could make the
> cycle collector better somehow to deal with it.  Or both.
> 
> It really isn't that illogical.  It is really great that Firefox addons can
> do all sorts of crazy stuff, but the flip side of that is that they can
> cause immense problems, and unfortunately right now it is really hard to
> tell what is to blame.  But anyways, a general lesson here is that if your
> Firefox is behaving horribly badly then try disabling your addons. 
> Hopefully in the future we'll be able to provide more useful feedback to
> users about which addons may be negatively impacting them.
> 
> So, to summarize, these addons were causing some amount of trouble?
>   FireShort 0.96
>   It's All Text! 1.6.3
>   TinEye Reverse Image Search 1.1

That is correct.  The problem subsided considerably with the removal of 'FireShot'.  FF also improved with the subsequent removal of 'It's All Text!'.  There was marginal improvement after removing 'TinEye Reverse Image Search 1.1'.

In essence, any add-ons beside the ones I was able to keep had an adverse effect on FF.  (Those were the only add-ons I used in a very long time--perhaps that is why I had not experienced this before.)

For this reason, I will use FF without attempting to experiment with other add-ons in the future.
(In reply to Andrew McCreight [:mccr8] from comment #55)
> (In reply to Ivan Azymov from comment #54)
> > After uninstalling the Add-On, 'TinEye Reverse Image Search 1.1'@0237HRS, I
> > restarted FF.  I am using FB, and I've viewed several videos on YouTube, and
> > tabs open total 14.  AND, FF continues to function properly, 1Hr 52 minutes
> > later.  (It's almost 0430HRS now.)
> > 
> > This all proves once again that part of dealing with software problems
> > (until resolve in a more technical manner), is still alchemy and black magic.
> > 
> > I hope this empirical approach to solving this issue could help you in
> > finding out why FF otherwise fails to function.
> 
> Yes, that is very helpful!  Thanks for investigating.  Olli and I can look
> into whether that addon is doing something bad, or if we could make the
> cycle collector better somehow to deal with it.  Or both.
> 
> It really isn't that illogical.  It is really great that Firefox addons can
> do all sorts of crazy stuff, but the flip side of that is that they can
> cause immense problems, and unfortunately right now it is really hard to
> tell what is to blame.  But anyways, a general lesson here is that if your
> Firefox is behaving horribly badly then try disabling your addons. 
> Hopefully in the future we'll be able to provide more useful feedback to
> users about which addons may be negatively impacting them.
> 
> So, to summarize, these addons were causing some amount of trouble?
>   FireShort 0.96
>   It's All Text! 1.6.3
>   TinEye Reverse Image Search 1.1

The list of add-ons I am able to use without adverse effects:

AbBlock Plus
AdBlock Plus Pop-Up Add-On
BetterPrivacy
DownloadHelper
Easy YouTube Video Downloader
Mozilla Archive Format
UnMHT
YouTube Video Replay

With the exception of 'YouTube Replay' and 'Mozilla Archive Format', I have been using only the add-ons listed for a few years.
clearly by previous posts there has been problems since ver. 3 and i'm not alone in this issue. so whatever you did since ver 2 you need go back and see the difference in the written programs between ver 2 and ver 3. there lays the root of the problem. telling people to go elsewhere is not solving anything.
Who has told people to go elsewhere? The feedback is very useful, and it would be great to
file new bugs about each specific problem. CC me and Andrew.
Also, it would be great if you could try Nightly builds. There are some major changes which could
help. (And more changes coming)
Assignee: igor → nobody
(In reply to Olli Pettay [:smaug] from comment #59)
> Who has told people to go elsewhere? The feedback is very useful, and it
> would be great to
> file new bugs about each specific problem. CC me and Andrew.
> Also, it would be great if you could try Nightly builds. There are some
> major changes which could
> help. (And more changes coming)


>what does Nightly builds do for the average end user? 
>what can i expect?
>what will it do for me? 
>will it find the bug(s) and tell me in PLAIN ENGLISH
so it can be fixed? 

it would be great if ff told me in plain english what 
caused the crash/freezeup and put an end to this nonsense.
> so it can be fixed? 
> 
> it would be great if ff told me in plain english what 
> caused the crash/freezeup and put an end to this nonsense.

I agree.  Please post your vastly superior browser on Softpedia (or other site), so that I may assess and perhaps make the leap.

You don't have an enviable, exemplary browser to offer?  That's fine.  I'll roll my own.  Uhmm... right..after.. I learn the necessary languages, programming protocols, and resolve to produce absolute, flawless code.

/sarcasm
It's obvious that the use of some plug-ins are to blame (I tested thoroughly through trial-and-error until finally weeding out the problematic plug-ins [noted in prior posting on this thread]).

In light of the problems I experienced, it would be wise to have thorough testing done on most of the plug-ins and generate a list of ones which do NOT affect FF negatively.  Of course, such testing must be done by USERS.  For the time being, perhaps offering FF with an essential set of plug-ins known to work proficiently (as an option during install), may put many users at ease--maybe even win back a few.  A notice warning that plug-ins outside of those offered as part of the standard install may introduce instability should also be part of the install process.

My 2c
I've been using FF since resolving the previous problems on 20120219 (with up to approximately 36 tabs opened), without issues.
(In reply to Ivan Azymov from comment #62)
> It's obvious that the use of some plug-ins are to blame (I tested thoroughly
> through trial-and-error until finally weeding out the problematic plug-ins
> [noted in prior posting on this thread]).
> 
> In light of the problems I experienced, it would be wise to have thorough
> testing done on most of the plug-ins and generate a list of ones which do
> NOT affect FF negatively.  Of course, such testing must be done by USERS. 
> For the time being, perhaps offering FF with an essential set of plug-ins
> known to work proficiently (as an option during install), may put many users
> at ease--maybe even win back a few.  A notice warning that plug-ins outside
> of those offered as part of the standard install may introduce instability
> should also be part of the install process.
> 
> My 2c

I like this idea.  So much, in fact, I think you should file a new bug to cover your proposal.  In that bug, you may also:
1.  Refer to testing requirements, procedures, expectations for addons
2.  Promote the idea of some type of "trusted" versus "untrusted" message at the time of a new addon installation, which would act as a "disclaimer" for Mozilla.
3.  The "trusted / untrusted" verbiage should also show up for each entry in the Addon Manager.

Firefox has a bad reputation for memory / cpu usage, and it was once well-deserved.  Large improvements have been made in those areas, with more still to come.  However, the FF "ecosystem" is not made up of the browser alone.  Users demand solid, properly functioning software, and this concept should not only apply to "FF proper", but to any addon which integrates / interacts with FF.  Since Mozilla cannot control every addon out there, users should at least be informed / warned when installing software that is not "approved" by Mozilla, and also have 100% confidence in software that IS approved.

For this reason, I think your new bug should be a META bug, pulling in aspects from AMO, Memshrink, Snappy, and any other area that would need consulting.

Just my 2c
I would really appreciate it, as the reporter of this bug, if people would stop posting things in this bug that have nothing to do with the issue I reported.  Please feel free to file separate bugs on the issues you see, if any.

Given that Firefox 10 has shipped and that at ship point this bug was fixed, I'm going to mark this bug as fixed.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [qa-]
Because this issue has lots of info, I thought I would add something that I haven't seen mentioned.

I'm suffering from this issue, and have for a couple of years I think. Now using 10.0.2. After investigating I see that Firefox is eating an extra ~100 MB of memory every 15 seconds. It goes from ~1000 -> ~1100 MB, and promptly goes back again.

This coincide with the CC:
GC mode: full, timestamp: 1331659659577000, duration: 529 ms.
CC timestamp: 1331659663229000, collected: 3598 (3598 waiting for GC), suspected: 2135, duration: 2117 ms.
GC mode: full, timestamp: 1331659667759000, duration: 530 ms.
CC timestamp: 1331659670361000, collected: 101 (101 waiting for GC), suspected: 542, duration: 2135 ms.

That looks to me as the CC allocates huge amounts of memory, and that allocation is contributing to the freeze.
cycle collector does use some, in some cases quite a bit, memory when it runs.
Could you perhaps try nightly (http://nightly.mozilla.org/) to see if the situation is better there.
You could report to my bugmail address.

This bug is closed, so for any new issues related to cycle collection or garbage collection,
please file new bugs (after checking whether the bug is already filed), and CC me to the bug.
Thanks!
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: