Closed Bug 29194 Opened 25 years ago Closed 25 years ago

After some time using the browser, it starts to suck cpu power

Categories

(SeaMonkey :: General, defect, P3)

Product:
SeaMonkey
Component:
General
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: chutzpah, Assigned: waterson)

Details

(Keywords: perf)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; N; Linux 2.3.47 i686; en-US) Mozilla/m13 BuildID: 2000022409 After using the browser for awhile, closing and opening windows, it will start to use 100% of my CPU, even if there is only one idle window open. Reproducible: Sometimes Steps to Reproduce: 1. Start the browser, browse awhile on various, open and closing several windows while browsing 2. Keep an eye on the cpu usage (a CPU meter is very useful for this) Actual Results: The browser will eventually start using all the cpu power, no matter what you do, even if it is idle. Expected Results: Use an appropiate amount of cpu power for what you are doing.
chutzpah@linuxfreak.com, what pages are you browsing? how many windows are you opening nd closing before you hit 100% CPU usage. There are several bugs reported on CPU usage and I'd like to point this one at the coprrect people but need more information to do that.
I believe I've found out how to reproduce this one. Its really quite simple. Start apprunner. Create a second navigator window. Close the first navigator window. Voila. Official M14 build on Linux. Changing state to confirmed/new (hope I'm allowed to). Colin.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Damn. I tried this three or four times earlier at each time it reproduced the problem. I just tried it again (several times)on the same system using the same starting page and now I can't get it to reproduce at all. ARGGGHHH.
reporter - are you still seeing this on m14 and m15 nightlies? colin@theblakes.com - have you been able to reproduce again?
Sorry about the delayed reply on this, my ISP has been having some problems tonight. Yes I still get it in the latest builds, I cant get it to reproduce every time by doing a certain procedure, I just open and close windows for awhile and eventually it starts using up all my cpu, even when its idle (even with one windows open with the page fully loaded). I managed to reproduce it again tonight on the March 8th nightly, and its also in the m14 official release. Also, the latest builds seem rather slow compaired to before (pre-m14), but thats probably another/temporary issue.
In reply to asadotzler@netscape.net, I generally open between 3 and 6 windows and open and close them randomly. The pages I'm looking at are mostly fairly basic pages like www.slashdot.org and www.bluesnews.com. I have also reproduced this bug while browsing bugzilla bugs, I often use "Open Link in new window" to open a link, then after opening a few more, I will read them and close the window or continue browsing in it, depending on the content. I dont think it has to do with "open link in new window", as I tried tonight with the new window option on the file menu, and reproduced it.
cc;ing mr waterson. chris, do you know who should own this, or if there are bugs already like this?
Keywords: perf
I'm not sure if there are already bugs filed on this. I've seen it as well. I can own it for now.
Assignee: cbegle → waterson
I'm seeing this CPU suckage as well. My buildID 2000030316 (the M14+crypto build), on Linux. I tried colin's steps to reproduce (start mozilla, open new window, close original window) and the first couple of times this did cause the suckage. Another method that seems (at least for me) to work more consistently is: Start mozilla Open history Double-click one of the entries (I used a local file I'd viewed) Close the original window. See CPU load jump up. BTW - this bug appears to be very similar to bugs 24471 and 30660 (I'll let someone else be the judge and mark them as duplicates / update cc lists / whatever if required).
Status: NEW → ASSIGNED
Target Milestone: --- → M16
I've been seeing this for quite a while, and am still seeing it in my nightly CVS build. What gtop is showing me is a runaway thread. I have four mozilla threads, and one is burning 100% CPU. I don't have a precise test-case yet, but it appears to be triggered by a click-event, possibly in combination with multiple windows. I will speculate that the bug involves threads and an event-loop, maybe spinlocking. The behavior of buttons and links has in general become odd recently, often requiring wailing on them to obtain the desired effect. Possibly related. debian/unstable, sgi CVS linux, k6.
the odd button and link behavior that often requires wailing on them is bug 33952 (I think it was just fixed tonight)
33952 appears to be at least greatly improved, but I'm still seeing the same behavior with the bookmark sidebar. The 100% CPU bug is alive and well. I just did a fresh mozilla build and it went straight to 100% CPU on startup. Example from last night: destroy a few windows, hit a link in remaining one. CPU -> 100%, window follows link but becomes only semi-responsive to scroll-bar events: a focus-transfer to and from another mozilla window is required to cause appropriate redisplay. Gtop shows 1 mozilla-bin thread @ 100%CPU, three idle.
I just used the in-kernel debugger to find out that apparently mozilla is spinning between libglib, libgdk, libpthread, libxpcom, libnspr4 and other addresses. I think this bug is misnamed. With current build mozilla is reliably going to 100% CPU on startup.
I see this as well, on Linux with build 2000041606. Strace shows: ioctl(8, FIONREAD, [0]) = 0 poll([{fd=8, events=POLLIN}, {fd=6, events=POLLIN, revents=POLLIN}, {fd=13, events=POLLIN}], 3, 0) = 1 gettimeofday({956045982, 792293}, NULL) = 0 ioctl(8, FIONREAD, [0]) = 0 poll([{fd=8, events=POLLIN}, {fd=6, events=POLLIN, revents=POLLIN}, {fd=13, events=POLLIN}], 3, 0) = 1 gettimeofday({956045982, 792573}, NULL) = 0 ioctl(8, FIONREAD, [0]) = 0 poll([{fd=8, events=POLLIN}, {fd=6, events=POLLIN, revents=POLLIN}, {fd=13, events=POLLIN}], 3, 0) = 1 gettimeofday({956045982, 792854}, NULL) = 0 ioctl(8, FIONREAD, [0]) = 0 poll([{fd=8, events=POLLIN}, {fd=6, events=POLLIN, revents=POLLIN}, {fd=13, events=POLLIN}], 3, 0) = 1 gettimeofday({956045982, 793134}, NULL) = 0 ioctl(8, FIONREAD, [0]) = 0 poll([{fd=8, events=POLLIN}, {fd=6, events=POLLIN, revents=POLLIN}, {fd=13, events=POLLIN}], 3, 0) = 1 etc....
bug 30926 seems to address similar problem. It was marked fixed about 10 days ago. This one obviously isn't fixed but I just happened across that other one and thought I recognized the strace so I added a comment here.
I just cvs-built and tested._Apologies_but_mozilla_is_currently_converting_spaces_to scroll-down-commands,thus_the_underscores. I_can_no_longer_reproduce the CPU_burn_bug.
The problem is alive and kicking in build 2000041811. CPU pegged at 100% after entering the proxy setup panel. Task was mozilla-bin, and interestingly (maybe?), the contents of the main window did not resize when the window was resized.
Bug is still quite well in current CVS build on K6 Linux. I dragged a URL from the location area over to the bookmark sidebar, mozilla went to 100% CPU and became unresponsive. Chatter: Node #0: drop 'http://www.villagevoice.com/issues/0018/howe.shtml' from container 'null' action = 'after' target = 'http://www.lemonde.fr/'
Jim Bray is referring to bug 38233. Can anyone reliably reproduce otherwise in current builds?
not nsbeta2, move to M17
Target Milestone: M16 → M17
pavlov: I think your magic event queue changes may have fixed this. check that shit in!
pavlov bryner alecf event foo fixed this
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
this bug needs a more qualified QA contact or someone to verify it or something.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.