Description of problem: The browser opens 2 windows, one on an MRTG page (standard config, 5 minute reload) and one on a Big Brother monitoring page with 20 systems refreshing every 90 seconds. Uptime is: 11:24:01 up 10:54, 3 users, load average: 2.24, 2.00, 1.23 Firefox opened by root within 3 minutes of boot (from top): PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2121 root 16 0 217m 66m 26m S 3 3.3 31:02.00 firefox-bin Memory cache device Number of entries: 261 Maximum storage size: 24576 KiB Storage in use: 10685 KiB Inactive storage: 5537 KiB There's a significant disconnect between what firefox thinks it's using and what the kernel has allocated to it. It becomes impossible to keep the system up for more than about 36 hours before it starts madly swapping and has to be hard rebooted. The CPU time usage is also way out of whack with what the process is doing. The pages are essentially static, the BB page has a couple of 32x32 animated gifs, but there is no javascript, java or other stuff. 30m of CPU out of 11h uptime is excessive. Version-Release number of selected component (if applicable): firefox-2.0.0.4-2.fc7 How reproducible: always Steps to Reproduce: 1. Open firefox on 2 pages (mrtg & bb) 2. Wait 3. Actual results: Significant CPU & Memory usage. Expected results: Minimal CPU, static memory. Additional info:
At this point, we're going to only be taking security fixes and major stability fixes into this release of Fedora. However, we still want to ensure the bug is fixed in the next version. We'd appreciate if you could test Firefox 3, available at http://www.mozilla.com/en-US/firefox/all-beta.html or now shipping as the default in Fedora rawhide and provide feedback as to whether it still exists so we can file a ticket upstream to try to fix it in Firefox 3 before it is released.
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA. [This is a mass-closing request, if you think that this bug shouldn't be closed, please, reopen with additional information.]