Closed Bug 276513 Opened 20 years ago Closed 15 years ago

URL slow to load, CPU gradually increases toward 100% and gradually increased memory usage. Slow response to link click. Slow to close the tab

Categories

(Core :: DOM: Core & HTML, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: rstanile, Unassigned)

References

()

Details

(Keywords: hang, perf, qawanted)

Attachments

(1 file, 1 obsolete file)

when page is completely loaded, and you try to select one of albums on the left
side, firefox consumes 100% of cpu, increases taken memory continuously and thus
hangs up, but you can try to close tab and after several minutes page closes and
everything returns to normal state. 

The javascript uses on this page is the cause, another Browsers don't react in
this way. 

Sorry for my english, I can tell you in details everything, but I think you are
pretty inteligent and can find everything out  as well :)
Due to the heavy use of setTimeout calls in the js code, I recommend this be
duped against bug 273797.  As the reporter says, it's not "hung" (as the summary
suggests) or frozen, it's simply very very slow to respond.  Note that on this
P4 2.8 GHz, task manager shows <50% CPU usage.
Please don't dup performance bugs unless you've done a profile that indicates
that it's the same problem. Mark things dependent if you're not sure they're the
same.
to be exact, my versuin of Browser is: 
Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.7.5) Gecko/20041108 Firefox/1.0
The URI provided seems to be non-existent now.  Is there another page that could
be used for testing this, or could we get a reduced testcase here?
the page moved (and changed a little bit) to URL: 

http://rajna.9online.fr/pages/la_discographie_de_rajnapag.html

but the bug still exists - even on the newest Firefox 1.0.2. Also Firefox 
starts consuming a huge amounts of memory, except a 100% processor utilisation. 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050413
Firefox/1.0+

Firefox uses 99% CPU power and starts to consume more and more RAM at about 50k
at a time when you goto that URI.  It doesn't 'hang' per se, but it does sit
there for quite a while and not redraw etc, and then it will redraw and show the
page again whenever you click on something.  Nonetheless, there apppears to be
some sort of issue.

Steps To Reproduce:

1. Open Task Manager so you can monitor resource status
2. Goto http://rajna.9online.fr/pages/la_discographie_de_rajnapag.html
3. Watch as firefox.exe process takes 99% of CPU and begins to slowly but surely
suck up more RAM
4. Click on one of the albums on the right
6. Wait for a moment while observing that the window doesn't want to redraw, etc
7. Attempt to close the tab.
8./Eventually/ it will redraw the screen and show up, but it takes forever, and
/looks/ like it is lurching along trying to crash.

Actual Results:

Firefox consumes all the CPU power available, and increases it's memory
consumption at an exponential rate.  Window refuses to redraw, minimize,
maximize, or respond in any other way after you click on one of the albums on
the right side.   After you click to close the tab this 'hang' (which isn't
really) lasts anywhere from 1 to 3 minutes, and then the screen redraws and the
tab closes and everything is 'back to normal'.  It is always extraordinarily
laggy on that page.

Expected Results:

CPU and memory consumption stays relatively the same, the program does not stop
responding at any time (even though it started again).

Changing URL to match that given by the reporter in comment #5.

Per comment #2, I am going to mark this dependant on bug 273797, as I am not
sure to go about how to prove it is an exact duplicate.

I am cleaning up the summary.

I am going to go ahead and confirm this, but I am not sure exactly which
product/component this belongs in, I will ask somebody else and be back along to
move it in a minute or so.  

Adding perf and qawanted keywords, this needs a reduced testcase.
Status: UNCONFIRMED → NEW
Depends on: 273797
Ever confirmed: true
Keywords: perf, qawanted
Summary: firefox hangs up because of simple javascript → Firefox will begin to use all available CPU resources and gradually increase memory usage while appearing to not respond. It doesn't actually hang, but does take a moment to start responding to trying to close the tab.
Whiteboard: testcase-needed
Thanks to Grey Hodges for letting me know which component this belongs in.  I am
actually going to remove the dependency I added above.  This doesn't appear to
be remotely the same as 273797, or to have similar symptoms associated with it,
and in fact, I was unable to reproduce 273797 on Win32, it appears to be a Mac
thing.  Sorry about all the bug spam, I went on comment #1 without checking...my
bad.
Component: General → JavaScript Engine
No longer depends on: 273797
Product: Firefox → Core
Version: 1.0 Branch → Trunk
Assignee: firefox → general
Component: JavaScript Engine → DOM: Level 0
QA Contact: general → ian
Attached file Simplified test case (obsolete) —
I experience this bug on Linux on two completely different setups. I've created
this simplfied test case which i've tested on:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050506 Firefox/1.0+
running on Mandriva 10.2 (2005LE)
Comment on attachment 182952 [details]
Simplified test case

sorry I'm meant this to go in 272797.
Attachment #182952 - Attachment is obsolete: true
Comment on attachment 182952 [details]
Simplified test case

sorry I'm meant this to go in 273797.
perhaps a dup of one of these http://tinyurl.com/ra6ff or a timer bug? 

similar results in seamonkey**. If running long enough the UI essentially hangs, with response in measured in minutes or not at all and no repsonse to clicking links.

early in the process, when the browser UI is responsive, response to closing tab is immediate - no delay. Later, closing tab takes a few minutes.  Interesting - the vertical list of links down the left side highlight when moused over, but don't response to clicks.

**Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060625 SeaMonkey/1.5a


with FF trunk*** the full web page never displays, even though the status bar indicates it's done loading.
when I tried to /quit chatzilla, which I had running obviously, I got

  Disconnecting from IRC. Click close again to exit now.
  [ERROR] Internal error dispatching command “quit”.
  [ERROR] (null): Component returned failure code: 0x804b0014 [nsIOutputStream.write] @ <chrome://chatzilla/content/lib/js/connection-xpcom.js> 453

*** Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060612 Minefield/3.0a1
Keywords: hang
Summary: Firefox will begin to use all available CPU resources and gradually increase memory usage while appearing to not respond. It doesn't actually hang, but does take a moment to start responding to trying to close the tab. → URL slow to load, CPU gradually increases toward 100% and gradually increased memory usage. Slow response to link click. Slow to close the tab
The last releases of mozilla-suite, seamonkey and Firefox are nearly unusable on my mandriva 2006. as soon as there are at least two tabs, the navigation becomes very very very slow, switching between tabs is an horror. I haven't noticed such a problem on windows releases, and it seems that the debian version, even if slower than window's, is much faster.
With all files saved locally (using "save page as..." and "web page, complete") my CPU usage goes up to about 50% and then drops slowly.  Still abnormal CPU usage, I think, but firefox doesn't get slow or hang as with the above URL. 

Then I compared the above URL and http://www.rajna.net/music/pages/otherwisepag.html (which both "hang") 
to 
http://www.rajna.net/music/pages/rajnapag.html and http://www.rajna.net/music/pages/intropag.html which both behave much better.

that's all I've got at this point.  
So has someone managed to create an offline copy that shows the problem?
I managed, it is available at address: 

http://eggdra.one.pl/~washuu/www.rajna.net.zip

Unzip, and load page www.rajna.net\music\pages\the_discography_of_rajnapag.html. The bug still exist, on my browser:

Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1

Great.  Next step is to make it as small as possible while still showing the problem.... ;)

For what it's worth, I did profile and as far as I can tell the site is just setting a _lot_ of timeouts to animate a _lot_ of images.  The question is whether this is just a bug in the site or what.
Tristor in comment #7
> Thanks to Grey Hodges for letting me know which component this belongs in. 

no description of why the component change  to DOM 0, but this web page has 40k of javascript (lmpres40.js) behind it - an ancient 1999 era version of LMSOFT Presenter

bz

reduced testcase attached (not a minimal testcase) - replace this file of Rafal's zip file of comment 16.  If you uncomment [1], [2], [3], [4], or [5] you see the problem behavior.  If you uncomment [11]-[15] cpu increases, but in the couple minutes I tested it does not hang firefox.  Perhaps someone can run with it from here with an analysis or further reduced testcase.


note also, while the UI is still responsive doing an "exit" also fails, if you let it run a bit first
1. load url
2. wait 1-2 minutes
3. file|exit or click the red X
4. select OK at the prompt to "do you want to close X tabs"

result: eventually the close prompt may go away, but cpu loop continues

memory increases, but only modestly
does this happen on linux or mac?
Assignee: general → nobody
Severity: major → critical
QA Contact: ian → general
Whiteboard: testcase-needed
bz in comment #17
> For what it's worth, I did profile and as far as I can tell the site is just
> setting a _lot_ of timeouts to animate a _lot_ of images.  The question is
> whether this is just a bug in the site or what.

FWIW the problem does not occur in IE. 

That's basically still relying on the huge JS libraries, no?  Those are what could use minimizing...
(reporter seems to be gone)

(In reply to comment #21)
> That's basically still relying on the huge JS libraries, no?  Those are what
> could use minimizing...

bz, what do you mean by minimize?
I mean remove as much code as possible while still demonstrating the problem in question.
my attachment of comment 18 is I think a pretty good reduced testcase of the web page html.  the difference of commenting out or in just one line causes performance problems.

but I have no idea how to minimize the library and there is no structure to it afaict that would lend itself to editing or examination without some tool.
Generally, you minimize the library by removing all the parts the code doesn't use, and then simplifying the parts that it does use.  I'm not saying it's easy, just that it's a big help in debugging.  Otherwise whoever is debugging more or less has to do it themselves to isolate the problem.
wada, do you have any expertise in this area?
Searching for "cpu usage" showed a large number of bugs reporting excessive cpu hogging.  This bug was found by searching for "cpu slow link".

I exceeded my ISP's monthly quota and got throttled back to 64 kB/s up/down from 256 kB/s up/down.  I then noticed that Firefox started hogging cpu and consuming large amounts of memory (500 MB, but I have 2 GB, so no problem).

Because I have typically 36 to 50 tabs reloading on launch, it is not surprising that there is a heavy download.  But at 64 kB/s Firefox does not NEED to hog the cpu.  The same behaviour occurs if I download some app installers.  I.e., it is the download process itself, not any local processing of Javascript, etc. that seems to be the problem.

I also note that when idle it hogs the cpu but seems prepared to give up cycles when another app launches or does something cpu-intensive.

This bug may be related to bug 254884.

Firefox 2.0.0.10 on Windows XP Service Pack 2, with automatic updates enabled (i.e. as recent as machinely possible!).
I can't get the URL to load.

do you see this problem with current beta of 3.1?
 http://www.mozilla.com/en-US/firefox/all-beta.html
I loaded the test cases in comment 14 okay in Firefox 3.07, with a much higher bandwidth available. Is it possible to install 3.1 beta side by side with 3.07?
(In reply to comment #29)
> I loaded the test cases in comment 14 okay in Firefox 3.07, with a much higher
> bandwidth available. Is it possible to install 3.1 beta side by side with 3.07?

Yes, just make sure it installs into a different directory. If necessary, use custom install checkbox during install
was VERY bad on firefox 2,  however, i have not been able to reproduce this problem on any browser after 3.0.4  (Note:  I'm not claiming that 3 to 3.0.3 also had the bug, just that I can't see the issue on 3.04 and later.)
If others can confirm, it might be interesting to figure out when this improvement happened....
Also, please indicate which exact testcase you're using and how you're loading it.
WFM per comment 31
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: