Closed Bug 66271 Opened 24 years ago Closed 23 years ago

Browser uses ~100% CPU after loading page

Categories

(SeaMonkey :: General, defect)

Sun
Solaris
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: gtr, Assigned: asa)

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; SunOS 5.8 sun4u; en-US; m18) Gecko/20010110 BuildID: 2001011021 I loaded a page which included HTMl and JFIF images supplied via calls to CGIs. The page loaded normally, and the stop button greyed out after the load. But the process was still using all the CPU! I killed the browser, restarted, and when back to the same page, but couldn't reproduce the fault. This has happened before, randomly, on various pages. Reproducible: Couldn't Reproduce Here are the leading entries from top, about five minutes after I noticed the problem: load averages: 1.11, 1.19, 1.22 13:38:14 67 processes: 65 sleeping, 1 running, 1 on cpu CPU states: 0.0% idle, 69.7% user, 30.3% kernel, 0.0% iowait, 0.0% swap Memory: 256M real, 91M free, 198M swap in use, 996M swap free PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND 11387 gtr 7 49 0 48M 38M run 104:10 98.29% mozilla-bin 10845 root 1 59 0 22M 67M sleep 1:15 0.36% Xsun 11696 gtr 1 59 0 6936K 4904K sleep 0:00 0.15% dtterm 12090 gtr 1 59 0 1552K 1352K cpu 0:00 0.05% top 11223 gtr 1 49 0 6840K 4576K sleep 0:00 0.05% dtterm It looks like it may have run away earlier, but in such a way that the runaway threads or whatever didn't stop the browser working. That's annoying, because it could have been any of a dozen pages where it originally went wrong. Or maybe it really _used_ 104min of CPU today. On the console, it said: JavaScript error: chrome://communicator/content/securityUI.js line 29: Components.classes['@mozilla.org/secure_browser_ui;1'] has no properties
do you have a test url?
the javascript error appears because you do not have PSM installed. I guess it is not relevant in the description of this bug.
Try http://cass03.ast.cam.ac.uk/cgi-bin/wfspreview/wfspreview.cgi?153149&ra=10:00:00&dec=00:00:00&radius=30 This doesn't reliably reproduce the mozilla problem, but is very similar to the URL where I saw the problem. It hits a bug in my CGI where animage/jpeg header is returned but no bytes of content; this might be a co-factor. Try http://cass03.ast.cam.ac.uk/cgi-bin/wfspreview/wfspreview.cgi?159871&ra=10:00:00&dec=00:00:00&radius=30 if you want a test-case where the CGI works.
I am not seeing this. Might be a unix only problem. Platform: PC OS: Windows 98 Mozilla Build: 2001020104
neither of the above URLs cause a cpu spike or lockup on my linux mozilla build 020210.
Both above-mentionned urls give me a "software error", apparently a syntax error. Any idea under which component this should go? Is there any item on that page which, once removed, prevents the bug from triggering? Please reassign if you find anything relevant. Thank you!
WORKSFORME Platform: PC OS: Linux 2.2.17 Mozilla Build: 2001030108 Reporter what version of XFree are you using?
> Reporter what version of XFree are you using? I'm not using XFree, I'm on Solaris 8 using CDE. My X server is the one shipped by Sun and installed in /usr/openwin/bin.
Reporter is this still a problem in the latest nightlies?
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter: Is this still a problem with a more recent build ?
As far as I can see without undertaking extensive tests, this particular bug is no longer present in recent builds. There are problems with downloads of dynamically generated images, but they don't involve using up all the CPU.
Thanks for your answer ! I mark this bug worksforme, please reopen if you see this again ! Downloading of dynamically generated images should be another bug...
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.