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)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: rstanile, Unassigned)
References
()
Details
(Keywords: hang, perf, qawanted)
Attachments
(1 file, 1 obsolete file)
|
24.79 KB,
text/html
|
Details |
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 :)
Comment 1•20 years ago
|
||
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.
Comment 2•20 years ago
|
||
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.
| Reporter | ||
Comment 3•20 years ago
|
||
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?
| Reporter | ||
Comment 5•20 years ago
|
||
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
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
Comment 8•20 years ago
|
||
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 9•20 years ago
|
||
Comment on attachment 182952 [details]
Simplified test case
sorry I'm meant this to go in 272797.
Attachment #182952 -
Attachment is obsolete: true
Comment 10•20 years ago
|
||
Comment on attachment 182952 [details]
Simplified test case
sorry I'm meant this to go in 273797.
Comment 11•18 years ago
|
||
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
Comment 12•18 years ago
|
||
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.
Comment 13•18 years ago
|
||
Now trying to make a testcase from http://www.rajna.net/music/pages/la_discographie_de_rajnapag.html
Comment 14•18 years ago
|
||
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.
Comment 15•18 years ago
|
||
So has someone managed to create an offline copy that shows the problem?
| Reporter | ||
Comment 16•18 years ago
|
||
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
Comment 17•18 years ago
|
||
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.
Comment 18•18 years ago
|
||
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
Comment 19•18 years ago
|
||
does this happen on linux or mac?
Assignee: general → nobody
Severity: major → critical
QA Contact: ian → general
Whiteboard: testcase-needed
Comment 20•18 years ago
|
||
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.
Comment 21•18 years ago
|
||
That's basically still relying on the huge JS libraries, no? Those are what could use minimizing...
Comment 22•17 years ago
|
||
(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?
Comment 23•17 years ago
|
||
I mean remove as much code as possible while still demonstrating the problem in question.
Comment 24•17 years ago
|
||
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.
Comment 25•17 years ago
|
||
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.
Comment 26•17 years ago
|
||
wada, do you have any expertise in this area?
Comment 27•17 years ago
|
||
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!).
Comment 28•16 years ago
|
||
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
Comment 29•16 years ago
|
||
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?
Comment 30•16 years ago
|
||
(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
Comment 31•16 years ago
|
||
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.)
Comment 32•16 years ago
|
||
If others can confirm, it might be interesting to figure out when this improvement happened....
Comment 33•16 years ago
|
||
Also, please indicate which exact testcase you're using and how you're loading it.
Comment 34•15 years ago
|
||
WFM per comment 31
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
| Comment hidden (offtopic) |
You need to log in
before you can comment on or make changes to this bug.
Description
•