292562 - 90% cpu utilization even when Firefox minimized after more than an hour

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Peter]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Build Identifier: 1.0.3

I don't have a specific URL that this occurs for.  But several times I have had 
to close Firefox using the Task Manager ... when the PC becomes totally 
consumed by Firefox ... even though it is minimized and have not loaded any new 
pages for minutes or even hours.  In these situations Firefox is unresponsive 
and I am unable to determine what caused the instability.  Please advise if and 
what diagnostics I could attempt prior to forceable shutdown by TaskManager.

Reproducible: Sometimes

Steps to Reproduce:
1. So far, I have not observed a predetermined sequence that leads to this 
situation
2.
3.

Actual Results:  
n/a

Expected Results:  
n/a

Please advise what diagnostic precautions I should take either before or after 
a lockup occurs.  Since this happens only occasionally, I have not observed any 
consistent precursor.  

I have seen similar bug reports for Linux, Mac and even WinXP ... but not for 
Win2k (server) ... is this something that is unique to each OS or systemic for 
all OS versions?

Finally, if this not a known bug ... what can I do to help you to nail it down?

Suggestions?

Comment 1

[Matthias Versen [:Matti]]

Do you use extensions ?

Comment 2

[Peter]

2005-06-01 ... one month later, this problem still persists ... must be a DO 
WHILE NOTHING loop buried somewhere in the code.  This only happens 
episodically, so far have not discerned any predictable sequence to set-up this 
failure.  When it happens, I usually do not have the patience to wait for Task 
Manager to float up the stack while CPU is 100% utilized by Firefox (doing 
what?!?) ...

Comment 3

[Matthias Versen [:Matti]]

You failed to answer one simple question and your description is to general to
do something. It's known that Mozilla and also FF is slow for a moment if you
minimized it over a long time because windows swapped Firefox out of the memory.

Comment 4

[Wayne Mery (:wsmwk)]

How much memory on your w2000 system and what other applications are open when
your system gets "consumed"?

Also, you might try a new build from mozillazine.org (FF 1.0.4 for example or
trunk nightly) in safe mode.

Comment 5

[Wayne Mery (:wsmwk)]

-->INVALID

Pedro, 
Reopen if still a problem and provide more details and the version of Firefox
from help|about mozilla firefox

Comment 6

[Peter]

2005-07-14:  This problem has not resurfaced since I upgraded to release 1.0.4 
from release 1.0.3.  I am not sure if this means that there has been a fix in 
the last update ... since this is an intermittent and unpredictable failure 
mode.

Comment 7

[Peter]

(In reply to comment #1)
> Do you use extensions ?

Yes, one, DOM Inspector 1.0

Comment 8

[Peter]

(In reply to comment #3)
> You failed to answer one simple question and your description is to general to
> do something. It's known that Mozilla and also FF is slow for a moment if you
> minimized it over a long time because windows swapped Firefox out of the 
memory.

What question?  Even if FF is swapped out of memory, it should not keep the 
platform locked up even after I have closed every other application.  When this 
has happened, FF still consumes all available CPU time (not necessarily all 
available memory) ... so this should not be about swapping out of memory ... 
clearly FF is using the CPU for doing some unproductive task.  To give you 
context, I have gone out for around an hour for coffee or lunch break, only to 
find that FF is still consuming close to or exactly 100% cpu.

Comment 9

[Peter]

(In reply to comment #4)
> How much memory on your w2000 system and what other applications are open when
> your system gets "consumed"?
> Also, you might try a new build from mozillazine.org (FF 1.0.4 for example or
> trunk nightly) in safe mode.

I have 640Mb RAM on a Win2k Server.  This situation typically arrises when 
multiple applications are active.  However, it fails to resolve even when all 
other applications are closed ... even one hour after all other applications 
have been closed.  This is why I suspect that it is busy in an endless do while 
loop or some other unproductive cpu utilization.

Comment 10

[Peter]

(In reply to comment #5)
> -->INVALID
> Pedro, 
> Reopen if still a problem and provide more details and the version of Firefox
> from help|about mozilla firefox

This problem was observed with FF 1.0.3 ... I am now running FF 1.0.4 and since 
then I have not observed this failure mode ... but since it is an uintermittent 
failure mode, I have never been able to determine failure precusors.

Comment 11

[Peter]

I am now using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.9)
Gecko/20050711 Firefox/1.0.5 and this problem has resurfaced.

Originally, the problem was observed with 1.0.3 and was not observed at all for
1.0.4 (although only briefly on that version). 

At least on this occasion, this ocurred after the system was idle for over an
hour (dinner break).  Initially, the system appeared to behave normally, then
the cpu was again consumed by Firefox.

I believe I have answered any and all questions above.  What next?

TIA

Comment 12

[Peter]

It has been FIVE MONTHS since this bug was submitted, and yet through various
updates (currently 1.0.7), the problem persists.

Mozilla still gets into some undefined state where it almost totally consumes
CPU resources when it is apparently doing NOTHING.

This is a CRITICAL bug, and I totally fail to understand why you seem to ignore
this profound issue.  Jusat because you don't know why this is happening is no
reason to bury your heads in the sand.

I do not for one nano-second believe that I am the only one finding this
problem, although I do believe that many who do, fail to report it and/or switch
back to IE.

I have tried to change the status from UNCONFIRMED, but Bugzilla will not let
me.  Whether or not you accept this, I can assure you this is a very real and
massively frustrating problem.

Is anyone going to take this seriously?  Ever?!?

Thanks in advance,

All But Totally Discouraged Firefox Supporter

Comment 13

[Wayne Mery (:wsmwk)]

(In reply to comment #12)
> It has been FIVE MONTHS since this bug was submitted, and yet through various
> updates (currently 1.0.7), the problem persists.

in fairness, two of those months were awaiting YOUR feedback so the process
could move forward. The bug was marked invalid only after no useful response was
forthcoming.


> ... Jusat because you don't know why this is happening is no
> reason to bury your heads in the sand.

it reaches developers when it is confirmed by someone else and (preferably) has
documentation to allow the developer to duplicate the conditions and thereby
find a solution - as of today we have none of those things.

 
> I do not for one nano-second believe that I am the only one finding this
> problem, 

There are many such bugs - some never get resolved or confirmed. The leading
factors to getting them resolved are good information and being able to
reproduce the problem. able.  If you have bug numbers of bugs that match your
situation that will be helpful.

from comment 0
>if this not a known bug ... what can I do to help you to nail it down?
from comment 12
> ... Firefox Supporter

In which case you can help your own cause by doing or answering the following:

a) install http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.5b1 and
report if the condition goes away
b) cite the URL(s) in use at the time of the hang (can be copied from history)
c) 1.0.4 where it didn't happen "often" may be a coincidence or may be a clue
and something we might follow up on later
d) When did you first install FF? Did you ever NOT have the problem with FF?  
e) e1. has it ever happened when there were NO other applications running? If
the answer is no, then e2. only one or two aplications open? (please name them)

And some general questions about your PC:
* computer model, cpu?
* how many MB disk free?
* when was disk last defragged?
* what type of internet connection?


It's primarily up to you as to how well this progresses.  Since by your
description you can almost create this condition whenever you want, ironically
though perhaps frustrating, this should help us identify the problem.

Comment 14

[Matthias Versen [:Matti]]

It's known that Mozilla/Firefox is slow after a long time minimized and we have
a bug for that. 
Nobody else got the problem that Firefox consumes 90% all the time. That's also
the reason why this bug is still unconfirmed because it can't be reproduced by
someone else.

Comment 15

[Peter]

(In reply to comment #13)
> (In reply to comment #12)
> > It has been FIVE MONTHS since this bug was submitted, and yet through 
> > various updates (currently 1.0.7), the problem persists.
> 
> in fairness, two of those months were awaiting YOUR feedback so the process
> could move forward. The bug was marked invalid only after no useful response 
> was forthcoming.

This was my first bug report, and I was not aware of any response to my initial 
report until I received an email to point this out, and then I respondedd 
immediately.  Now I know better how Bugzilla works.
 
> > ... Jusat because you don't know why this is happening is no
> > reason to bury your heads in the sand.
> 
> it reaches developers when it is confirmed by someone else and (preferably) 
> has documentation to allow the developer to duplicate the conditions and 
> thereby find a solution - as of today we have none of those things.

I do, of course, understand that it is difficult to know where to start when it 
is an intermittent problem.  I do, though, have to suspect that there is a 
condition which allows FF to fall into an endless do nothing loop.  Even if you 
do not (yet) know the cause and the conditions under which this can occur, may 
I suggest a debug code segment that will generate a bug report automatically if 
FF is active for extended time without a user request for action.  This would 
be code that runs concurrently with the core application ... and part of an 
overall test and monitoring algoritm.  Absent any conclusive way to predict or 
reliably produce this failure mode, this is the logical next step to "trap" the 
failure condition.

In the past I have not only developed single board computers and developed 
compilers for same.  During this process many frustrating and unpredictable 
things happened.  If they appeared unpredictable or could not be relaibly 
reproduced, I would write a trap algorithm that ran concurrently with the main 
application ... and created a log file if any one of predefined things 
happened. 

With all due respect, I suggest that you consider this approach.  Probably FF 
already has such a test and monitoring algorithm.  In that case, this is just 
another failure mode to check for. 
  
> > I do not for one nano-second believe that I am the only one finding this
> > problem, 
> 
> There are many such bugs - some never get resolved or confirmed. The leading
> factors to getting them resolved are good information and being able to
> reproduce the problem. able.  If you have bug numbers of bugs that match your
> situation that will be helpful.

Unfortunately, it is frequently the case that there is not "good information" 
always available to track down bugs.  This has always been the case.

It does not suprise me that you have "many such bugs" with "some never get 
resolved or confirmed" ... if this is true, then it means that a new 
alternative approach is required to understand these "many such bugs"

But just to ignore them just because there is not a "smoking gun" is not a good 
way to develop bullet proof software.

As above, I would suggest ... no recommend ... that if you don't already have 
a "bug trap" built into FF to you fire up a tiger team to develop one ... and 
make it general enough that developers can add new conditions to trap and 
report and new "unconfirmed bugs" roll in.

If done systematically, you can mine a treasure trove of information from the 
installed base of FF.  Just think of the possibilities.


> from comment 0
> 
> > if this not a known bug ... what can I do to help you to nail it down?
> 
> from comment 12
> 
> > ... Firefox Supporter
> 
> In which case you can help your own cause by doing or answering the following:

My cause is to have a dependable browser that doesn't force me to close down 
other applications, use Task Manager to shut down FF and reboot.

I believe it is the cause of the Mozilla Foundation to establish market 
presence by delivering a stable and superior browser.

> a) install http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.5b1 and
> report if the condition goes away

This is the latest beta ... I am guessing from the jump from 1.0.x to 1.5.x 
that this is a major code update.  I will install and report back if the 
condition re-occurs.

> b) cite the URL(s) in use at the time of the hang (can be copied from history)

I have never recorder the URL(s) before and was not asked before.  I will note 
this down in future.  I doubt that this is related to any particular URL, or I 
would have noticed that before.

I do note, however, that it SOMETIMES occurs after the server has been idle for 
some time.  

From comment #3 "It's known that Mozilla and also FF is slow for a moment if you
minimized it over a long time because windows swapped Firefox out of the 
memory."

In my experience, whether or not the server has been idle, this is not a 
momentary problem ... it is persistent.  I have even gone to lunch when it has 
occured in the past, shutting down all other applications and non-essential 
processes before leaving ... and yet the server remains in a catonic state on 
my return with FF consuming CPU resources.

> c) 1.0.4 where it didn't happen "often" may be a coincidence or may be a clue
> and something we might follow up on later

As mentioned before, I only had 1.0.4 installed briefly before 1.0.5 was 
released so it is not at all clear that this problem did not exist with 1.0.4.

> d) When did you first install FF? Did you ever NOT have the problem with FF? 

I am not quite sure ... but I believe it was 1.0.  I had been watching FF and 
decided to wait till it got to release 1.0.

I first reported the problem with 1.0.3 and have observed it in most releases, 
including 1.0.7.  I don't recall it happening on earlier versions, but I 
reported it only after it had already happend several times ... possibly on 
earlier versions.
 
> e) e1. has it ever happened when there were NO other applications running? 
> If the answer is no, then e2. only one or two aplications open? (please name 
> them)

Generally there are several applications running ... I don't recall the problem 
occuring when only FF is running.  Except, as noted above, when it does happen, 
closing down all other applications does nothing to ameliorate the situation.

> And some general questions about your PC:

Please note this is not the same computer I was reporting on before.  I have 
two servers, one operating Win2k Server (English) and the other operating Win2k 
Server (Chinese) ... although FF is English version in both cases.  

I have observed this failure on both servers.  Currently only the Chinese OS is 
up (the other is having the RAID updated).

OS: Windows 2000 Advanced Server Service Pack 4 (build 2195)

> * computer model, cpu?   
Intel PIII 867 MHz
ASUSTeK Computer INC. CUV4X-E REV 1.xx   133 MHz bus clock

> * how many MB disk free?   
1.99 Gb free out of 19.5Gb

> * when was disk last defragged?  
Not sure exactly ... usually do every 2 - 3 weeks

> * what type of internet connection?
ADSL always on

> It's primarily up to you as to how well this progresses.  Since by your
> description you can almost create this condition whenever you want, ironically
> though perhaps frustrating, this should help us identify the problem.

I don't know where you got the idea that I can almost create this condition 
whenever I want.  :$   

I have done my part so far.  I will try Firefox 1.5 Beta 1 ... interested to 
see what is new too.

But I cannot do much more than this.  But I think there are many things that 
can be done by the development team ... either about bugs they know and 
understand ... or to do things to learn about the bugs they don't (yet) 
understand.  In particular, I would encourage the team to build a bug trap (as 
described above) ... if such trap already exists, please add check for the 
conditions I describe.  There is a goldmine of bug data out there if Mozilla 
choses mine it.

Comment 16

[Wayne Mery (:wsmwk)]

(In reply to comment #15)
> > a) install http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.5b1 and
> > report if the condition goes away
> 
> I will install and report back if the condition re-occurs.

great, telling us if this fixes the problem (or does not) will help us move forward.

Comment 17

[Wayne Mery (:wsmwk)]

no reponse -> closing as INVALID