266367 - Performance degradation after a day or more open

Status: RESOLVED INVALID

(SeaMonkey :: General, defect)

Description

[Timothy B. Terriberry (:derf)]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020

After leaving the browser open for a day or more, performance degrades to the
point where just scrolling down in a plain text mail message will use 100% of my
CPU for several minutes, and bringing up minimized browser windows often takes a
minute or more of constant CPU churning. Sometimes it takes two or three days to
reach this point, but it always gets there eventually. Completely closing and
then re-opening the browser resolves the issue, but requires me to re-enter
passwords, re-open long running Java applets, and otherwise restore the windows
and tabs I was using.

Reproducible: Always
Steps to Reproduce:
1. Use Mozilla for several days continuously
Actual Results:  
Performance degrades to the point where even simple interactions become unusably
slow.

Expected Results:  
Maintained responsive performance.

Comment 1

[Thomas Lange]

I can confirm the very same behaviour for Windows and over the (at least) latest
three(!) major releases of Mozilla.

Though I usualy blamed it on having a larger number of windows and tab pages open.
It is not unusual for me to have about 4-6 windows with about 30-40 pages in all
open at once and over several days.
Especially since I often use hibernation mode and completely reboot usually only
once about a week. 

I have no idea if that problem is related to content of specific webpages but it
does exist in reality and if you're browsing for days using the same instance of
Mozilla it eventually hits. As measure of occurence I would say it is as often
as about 1-3 times in about two weeks.

But I can confirm that the CPU usage degrades over time.
(Not necessarily steadily though. For me it is usually that at some point I
notice it uses an unreasonable amount or even all of the CPU time.)
Even when nothing is done with Mozilla, all pages are already loaded since hours
and all windows are iconified I can eventually see the CPU usage to go to 80% or
higher on a 1.5GHz Centrino without any other program using CPU.

I don't know if it is a seperate issue but somes times after restarting Windows
from hibernation it gets especially terrible since it gobbles all of the CPU and
there is virtually no CPU left for the startup of the OS. It sometimes needed me
to wait about 30-45 minutes to just get the task manager raised and have Mozilla
killed. >_<
And I couldn't just reboot the system by hitting reset because I ended the last
session while having a debugger still running in a critical state. :-(
What makes it worse that Mozilla has no crash recovery at all by default and
thus it is a tedious task (if possible at all) to get all those open windows and
tab pages open again. The only chance for that is the history but it is really
not up to the task.
Of all programs I know Mozilla is the only one that makes this kind of trouble.
(Well of course I tried Firefox too but it has the same problem as well.)


Since I'm somewhat familiar with bug tracking systems and how they get used by
developers and QA, I took the liberty to raise the priority and severity and
also changed the target to the next beta in order to make sure that at least
someone takes a little notice of this way big problem.


Thomas->tterribe: It seems I cannot raise the severity since I'm not the
submitter. I suggest you raising the severity to major or even critical which
seems to be more approriate. Thanks!
Same applies to the OS. (This tool becomes annoying!)
Can you please set that to All too? 
That should significantly raise the priority of this issues since probably >90%
of the users use Windows.
Well... can't change the priority as well. (This tool definetly sucks. If I'm
not allowed to change those settings there shouldn't be a list box that I can
change in the first place!)

Thomas->tterribe: To sum it up:
Please change the following:
OS to ALl
Version to 1.7 branch
Priority to P1
Severity to major or critical and
Target milestone to mozilla1.8beta1

Thanks!

Comment 2

[Timothy B. Terriberry (:derf)]

Apparently, despite being the submitter, I am also not allowed to change these
fields.

Comment 3

[timeless]

well given that half your changes aren't changes we want you to make, i think
the fact that you aren't allowed to change them is a good thing.

note that your bug is 99% air. how about some details? at the very least keep
track of which pages, possibly use perfmon on various characteristics. this bug
as is should be killed w/in 1 week unless you provide *useful* details

Comment 4

[Thomas Lange]

Even so I quite well understand that not everyone is allowed to change
everything, I'm quite disappointed to hear that the common handling for harder
to reproduce bugs is to close them within one week with seemingly no one on your
side even trying to reproduce this one yourself.

I'm aware that this issues has not real substance to grab at immediately.
But I provided as much possible input as I could! Since it currently really
can't be tied down to anything specific it can't be helped.
But those usually are the cases where a skillfull QA is required to jump and try
to check things out.
A tiny sentence like "We will try when we have the time" would have been all to
put everyone at ease. And the target would have been set only in order for this
issue (that is for the need to check something out) to appear in the queries of
things that need to be done. Of course it wouldn't have meant that it will get
fixed for that release even if it was reproduced. 


And the program using all the CPU's power and thus being required to be shut
down, I would consider that a serious problem for any program.
Thus I'm quite puzzled that there seems to be no real interest in this issue at
all. What about the so much famed performance of Mozilla? 
From what you state It seems the value it is claimed to have in it's community
has much air in as well.

The idea to try to keep track of the pages visited is the only useful hint you
supplied in order to get on with this. But as I mentioned before it is somewhat
hard to keep track of them when you need to shut the program done and and the
history is usuallay filled with lots of links that git visited previously but
are no longer displayed. And if you clear it you are missing the ones that are
already open.

If there were some small lines of code that always dump the the visted URL that
are still displayed in the windows to a file it would be such a useful thing.
For once you would now be able to tell me where it would be and I could just
have a look at it and send it to your or try again with the same links if it is
reproducable with them, and on the other side it could be a first step towards
crash-recovery which would be a great thing as well. So I missing some kind of
support you could have given here in the first case as well.


However I will at least try resetting the history completly when starting
Mozilla in he future in order to try to get a grip on the displayed pages later.
But since a browser is naturally used to browse through many pages I'm afraid it
will be futile.

But actually I'm quite shocked about the attitude of task handling you display
here! Stating to close serious (or at least potential serious) issues without
ever really trying to check them yourself if no one is able to do the work for
you to pin-point them.

I think I must spend some days to decide if I should live with a big always
reoccuring problem you guys are not really interested to fix (or at least trying
to tracking it down) or if I rather should switch to a different browser.

I surely hope that this is not the kind of support you're trying to make money
with in the future.

Comment 5

[timeless]

we don't have such qa, and we know that mozilla slows down. give us something 
useful or wait for someone else to do the work somewhere else.