User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071221 Firefox/2.0.0.11 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071221 Firefox/2.0.0.11 There are three problems here. 1) Firefox will hang when requested to load too many pages. 2) Firefox becomes progressively slower loading the same page as the number of tabs increases. 3) When the number of pages (tabs) loaded is large Firefox may hang loading even a small number of pages at the same time. Reproducible: Always Steps to Reproduce: 1. Using a single-core, Pentium 4 (prescott) machine. 2. Run NYT-test.sh (to be attached) multiple times until Firefox hangs. Actual Results: If INTERVAL is set too low (1-5 seconds) Firefox will typically hang in the first 50 tabs launched. If INTERVAL is set to an intermediate value 6-10 seconds, Firefox will launch 50-150 tabs but will end up consuming 10-73% of the CPU (varying over time) when the nothing else is requested. Even with INTERVAL of 15 it is impossible to open 250 tabs. Firefox hangs with 22 hung tabs (the little "loading" icon on the top of each tab circling) out of 250 tabs opened. The browser will not switch between tabs or perform any functions (i.e. it is hung). Expected Results: Firefox should be able to load pages until I run out of swap space. Even if it maximizes the CPU it should still eventually respond to a tab switch request -- it should not deadlock and fail to complete page loading. The NYT-test.sh script was designed as a first attempt to produce the type of stress testing required for Bug #263160. But obviously one cannot produce a stress test of a Javascript timer going off every second if one cannot launch sufficent tabs to do that. I am surprised that Firefox has been released without this type of stress testing. Until Firefox can push the CPU and the Internet (Web) connection to 100% usage, it isn't ready for prime time.

The comments in the shell script are fairly self-documenting. As the NY Times is running refreshes of its home page every 15 minutes the goal is to open sufficient sessions to that page to force extremely frequent refreshes of one or more of the resulting sessions. This requires opening several hundred tabs but as the comments discuss Firefox has a difficult time doing that.

Severity may not be critical according to guidelines. Major might be more suitable. (I'd be more useful if I had a single-core cpu).

Its not that the bug will not appear on a multi-core CPU, its just that I have no way to try it currently. Doubling MAXSESSIONS and decreasing INTERVAL to 3-5 seconds might be a good place to start. It should be noted that I started with an INTERVAL of 5. That worked ok on the single (semi-dual) core Prescott up to 50-100 sessions. An INTERVAL of 3 hung at less than 50 tabs. Of course this is dependent on your browser-to-web bandwidth (e.g. DSL vs. Cable) the load on the line and how fast your DNS lookups are (the NY Times is serving from multiple servers) and whether or not the NY Times constrains bandwidth to a specific IP address (I doubt they do given the fact that internal nets may all look like the same IP address to the NYT). The point would be to decrease INTERVAL and/or increase MAXSESSIONS until one gets to the point where one has multiple sessions loading simultaneously -- if problems (hangs or delays in loading) arise then you have encountered the problem. If one decreases INTERVAL to 1 and increases MAXSESSIONS to 1000 and it still works then one would have to write a Linux shell timeout program that works in milliseconds rather than seconds. My indications currently are that you will max out a single (semi-dual) core CPU around 250 tabs. So even with a quad core you should max out with 1000 tabs.

Updated script, essentially corrections or expansions to the comments.

Here are some statistics. Setting MAXSESSION=100 and INTERVAL=30 and running NYT-test.sh twice yields a single window and 200 tabs on the NY Times home page. The statistics (from "ps") are: with 100 tabs: VIRT=384m RES=261m CPU=5-55% with 200 tabs: VIRT=665m RES=534m CPU=66-93% (mostly 88-91%) Over 4 hours (240 minutes) of "real time", firefox had used 200+ minutes of CPU time. It appeared that firefox was still running in that from time to time various pages would enter and slowly complete a page reload operation. It was not clear if one or more of the reloading tabs was "hung". It is worth noting that a separate process running a lengthy FTP download had completed and firefox effectively had 100% of the CPU and DSL line bandwidth to itself. The system has 1.5 GB of main memory so firefox was only consuming ~30-35% of memory and there was little or no swapping taking place. Tabs would become active and end up waiting for long periods on graphics8.nytimes.com (or other nytimes URLs). So while the test has yet to spring the infamous Bug #263160, it does point out a number of problems: 1) Too many pending javascript timeouts and/or page reload operations will drag firefox and the system itself into the ground by using up too much CPU time. (This is what happens when you let other people or institutions run programs, rather than simply display information on your computer...) 2) The collection of "children of firefox" is not handled properly. The NY Times home page invokes flash (directed to /usr/bin/gtk-gnash) on my system. I've modified gtk-gnash to be a shell script which immediately exits with a zero. These all end up as "zombie" processes (hundreds of them) because firefox doesn't wait for them. 3) Firefox fails to allow one to open tabs/windows until one reaches the physical memory or swap memory limits. The largest number of open tabs I've managed to coax out of the script is 228 after which firefox appears to permanently hang. 4) There is no firefox internal "ps" command so one can see precisely how many javascripts and timeouts are associated with each tab. If one opens 100+ tabs from digg.com, one may watch firefox & system performance drop through the floor, but one has no idea *which* URLs are the primary culprit (I've seen some sites start up 3-6 independently running javascripts). 5) There needs to be a preferences button (or maybe a per-tab button) option to suspend all "running/pending" javascript operations, similar to the "stop process" operation available from Gnome System Monitor so one can get control back from Javascripts run amok.

Are these results with trunk or with v2? Results would be more relevant and useful from a development perspective if done with trunk, and possibly compared to v2. And, I would suggest, install flashblock extension and see if you get different results.

Wayne, I do not recall. I suspect the initial bug report would contain the details. I usually run the production release of Firefox but from time to time wrestle with the prerelease versions. However the test case is very clear and can be used to effectively take down the browser. It should not be possible to take down a browser by bringing up several hundred identical windows from one of the major newspapers in the U.S. It should not be required to install a "flashblock" extension since I had already disabled gtk-gnash on my computer due to firefox's poor handling of flash extensions (for example limiting the runtime of flash scripts or collecting the child processes after termination). In a reasonably behaved browser, flash players should be limited to reasonable behaviors. As it appears advertisers, media producers, etc. want to keep shoving things through our eyes, there should be clear ways (in the default browser) to prevent this.

Ray, flash player is well documented to have *numerous* problems in the past few years (yes, as has firefox). What do you get with Firefox 3, and flash v10? And if it fails, results with flashblock?

at this point, testing with FF2 and even 3.0 are not useful, given the nearness of 3.1. please test with 3.1 beta - with and without flash 10 (flash 9 is history). http://www.mozilla.com/en-US/firefox/3.1b2/releasenotes/

=> incomplete without further feedback.