Closed Bug 380572 Opened 18 years ago Closed 18 years ago

runaway CPU with idle browser at fixed set of tabs - some with javascript

Categories

(Firefox :: General, defect)

2.0 Branch
x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED INVALID

People

(Reporter: bugz, Unassigned)

Details

(Whiteboard: CLOSEME 07/05)

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Avant Browser; Avant Browser; .NET CLR 1.1.4322) Build Identifier: v2.0.0.3 Dear Mozilla: Your products are wonderful. I am fully up to date on all patches for firefox v2.0.0.3, but I am lately seeing a frequently recurring problem of runaway CPU load attributed to the firefox process. I typically keep my firefox browser running to a fixed set of tabbed windows by which I monitor a few things at a glance, such as news, weather, and gmail. Many of the javacript ads on some of these sites are blocked by my guidescope.com proxy server, which could account for error conditions which the web pages are not designed to expect. However the result when the unattended operation results in consuming all CPU resources is an unmanagible machine, and perhaps a bug within firefox to let it go undetected. Prior versions of firefox would detect that something was wrong with a script, and abort its processing. This is not happening now. Is there perhaps an engineer who might want to try to repeat the problem within your lab and instrument firefox to find out what condition is resulting in the runaway javascript or other aspect of processing? My environment is a windows xp laptop, and I would be happy to provide any other data necessary to replicate the problem. Killing the process, if I can get task-manager's attention, and then restarting firefox results in being prompted to restore the previous session which then runs contently with negligible CPU time. Opening about:blank on top of the news web site to prevent its periodic polling of the web server has not prevented the problem, but I think this method should eventually divide and conquer the set of tabls to isolate which one is the culprit. Perhaps a feature to suspend all javascript processing if CPU time exceeds a specified threshold would help keep wintel computers managable even with bugs like this lurking. Reproducible: Always Steps to Reproduce: 1. 2. 3.
We'd need a list of URLs that you have open at the time to begin to investigate this problem. Also, can you please test with a new firefox profile ( http://kb.mozillazine.org/Profile_manager ) and see if the problem is reproducible like that?
try repeating with www.guidescope.com configured as proxy server and opening up tabs to www.jpost.com, www.weather.com (for some zipcode) and www.gmail.com. For whatever it is worth, I installed "minefield" v3.0 alpha 5 and tried my same tabbed set on it, and it got into a runaway memory usage state... although CPU remained tolerable. Also noteworthy is that task manager labels the minefield process "firefox". Please note that part of the problem could be javascript at the jpost site which expects certain ad-tracking things to happen which my guidescope configuration precludes, with this: $ grep jpost /cygdrive/c/program\ files/guidescope/block.ini static.jpost.com/images/2005/promos ads.jpost.com/RealMedia/ads ads.jpost.com static.jpost.com/images/2007/promos ~ads.jpost.com/RealMedia/ads/click_lx.ads jpost.us.intellitxt.com
It is very useful to clean up apparent memory leak excessive usage to bring up task manager, find and kill the firefox process (that name whether latest firefox or minefield alpha) and restart either browser, which then prompts, on startup, to restore the previous session. No work is lost on having tabs set to various states! My suggestion is to provide a "serialize and restart" button on the browser to "reboot" its memory usage, and perhaps to have an automatic invocation of this step when memory exceeds a certain user-specified threshold, after something like a 15 second warning by which the user can prevent it.
FWIW monitoring the memory usage of firefix, it grows, starting from about 60M at start with my usual tabs, and as it grows above 100M things get bad, but when it gets to 200M, I find it necessary to kill the process, restart firefox, and it nicely restarts the session where it left off after a few prompts, and all is well for a while. Closing the tabs themselves does not free the memory. It happens the same way with the latest firefox and the latest minefield. Is there any instrumentation to enable to determine which areas of memory usage?
Re: comment 1 - please try reproducing this problem with a new firefox profile: - http://kb.mozillazine.org/Profile_manager
from reporter via email: -------------------------------- Would you mind telling me what is a "new firefox profile", and how it will help trace or prevent the memory leak? -------------------------------- Firefox stored all your bookmarks, history, cookies, extensions, etc, in a profile. By making a new profile and seeing if the problem still exists, we can see if your problem is caused by an extension, theme or user setting or not. Note: When you make a new fx profile, don't delete your existing one! If you still see the problem with a new profile, then we need to look at your plugins (flash, shockwave, etc, to make sure they are up to date).
new profile created - with same set of startup tabs and stored passwords and proxy settings. One tab within guidescope is not quite working correctly, but its hardly used. The big likely culprits for memory leaks, jpost and gmail, with their javascript polling loops, are up and running. Memory usage is currently at 74MB, and I'll monitor it. It even now has that clean new-car scent! Thanks steve!
Steve is a genius! I just want to say that. The new profile has prevented the problem from recuring too badly.... The memory usage on initial use of the new profile was down at 70MB, and it is up to 110MB after not too long, and still holding around there at 130MB after a few days. If there is a way to export all the stored passwords from the original profile and import them to the new one, unrelated to this problem, that would help me out with using the new profile. But more important might be to figure out what is different between the two profiles if possible - to identify which module or area might be the culprit.
Severity: critical → major
http://kb.mozillazine.org/Migrating_settings_to_a_new_profile should help you migrate whatever settings you require from your old profile to your new one. It sounds to me like you had an extension that was causing problems, so an alternative to migration is to go back to your old profile, but start to disable your extensions one by one until the problem disappears. If you are satisfied that this problem /was/ caused by an extension, we should resolve this bug as INVALID. (Problem caused by third-party extension); but of course it would be very nice to know exactly what extension caused this problem!
Whiteboard: CLOSEME 07/05
Version: unspecified → 2.0 Branch
No response from reporter re: comment 9 -->INVALID (problem due to extension).
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.