75.26 KB, image/png
145.77 KB, application/octet-stream
205.58 KB, application/octet-stream
3.10 KB, text/plain
10.27 KB, text/plain
40.26 KB, text/plain
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030210 Chimera/0.6+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030210 Chimera/0.6+ I'm using the daily builds of Chimera (using ChimeraKnight to do updates) and have run into a problem the last few days where Navigator unexpectatly starts to use almost all of my processor. On the recomendation of some in the mailing list I've used Sampler to grab some info. I've uploaded it's report and a screen of the app in the sit file: http://homepage.mac.com/cyberzorn/temp/SamplerInfo.sit I'm trying to firgure out what the differences are between my home (RevA Ti500) and work (Dual Gig) setups, becuase I don't notice this problem at work. I'm curious if its connected to energy saver functions or sleep. I am aware of a previous bug that would cause CPU use to go up after sleep but these latest problems happen even outside of running navigator after sleep. Reproducible: Sometimes Steps to Reproduce: Start up Navigator, let it run .. in time CPU montior sky rockets. My home machine is RevA Ti500 / 512 / Airport / OS X 10.2.3 I have recived the problem while on AC power and on battery via the Ti. It is a fairly fresh install of 10.2.3, done a few weeks ago. I use nightly builds at work too (on a dual gig MDD) but haven't noticed the problem there.
The sampler data in the .sit file doesn't look consistent; it's upside-down, for one thing. Please sample again, but keep the Sampler default settings.
Created attachment 114457 [details] ThreadViewer data for Navigator sucking CPU I think Java threads might be a contributor to remaining CPU suckage issues. See the attached image, which is TheadViewer showing a very active thread (I clicked on the mainly green one), in JVM_NewInstance.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Excessive CPU usage by Navigator; Even while it's the backgroud app → Excessive CPU usage by Navigator, even while it's the backgroud app
*** Bug 169993 has been marked as a duplicate of this bug. ***
hmmm. is this still an issue? i see this on trunk builds, i figured it was timer issues but maybe it's not.
Assignee: saari → pinkerton
Target Milestone: --- → Camino0.8
I think I still see this now and again.
Me too. In addition I now have a normal production machine with no wonky firmware and it still shows up infrequently.
This is probably related to bug #227680.
i'm curious if anyone sees this with a build after 2/17/2004. i fixed a long-standing memory leak that might cause the enough of browser area to be leaked to be relevant. please let me know.
Status: NEW → ASSIGNED
I just saw this for the first time ever with my own build from 2004022616. Its still here.
I had it yesterday and it was eating up 75% cpu!
Summary: Excessive CPU usage by Navigator, even while it's the backgroud app → Excessive CPU usage by Navigator, even while it's the background app
FYI, I see this with other apps too, but generally Camino is the worst offender. Other offenders has been Fire (fire.sf.net) and iTerm (iterm.sf.net). All of these are Cocoa apps - the only connection I can think of. They are also run very long times. Other apps like iTunes or Finder never exhibits this behaviour. I'm on 10.2.8 btw. I think this is a general Mac OS X problem that Camino trips more than others. Roine
I can confirm the similar behaviour of Fire and iTerm. I actually reported a "Cpu usage after wakeup" bug for iTerm. Perhaps the information in another bugreport for iTerm is helpful: http://sourceforge.net/tracker/?group_id=67789&atid=518973&func=detail&aid=887656 I haven't seen this behaviour in Camino or iTerm during the last few weeks (I'm running OSX 10.3.3)
Not sure if this is the same bug, but a day after upgrading to Camino .08 I'm seeing a behavior where the browser operates perfectly to a point then, with two or three tabs open, it responds to a click on a new linking by simply going into "Loading" mode and not coming out of it. Looking at the same link in Safari, IE, and Firefox confirms the link and the network connection are functioning, hence I think that Camino is hung. The solution so far is to quit Camino and relaunch it. After that things work fine for a bit and then the same behavior is repeated.
that sounds totally different, but can you look in your console to see if there were any obj-c errors from Camino?
Summary: Excessive CPU usage by Navigator, even while it's the background app → Excessive CPU usage by Camino, even while it's the background app
I don't know why but with one of the recent betas (or with a changed behaviour from my side which I can't identify) the issue started again. About three to four times Camino started sucking CPU power without having any window open, restarting Camino fixes it. It might be related with sleep issues, I can't see any connection with the Java VM. The console didn't show any specific information which might be helpful. Camino nightly 2004052908 (v0.8b+) on Mac OS X 10.3.4 on Powerbook 15" 1,5 Ghz.
We really need to see Sampler or ThreadViewer data for periods of CPU suckage to figure this out.
every time i sample this or use threadviewer, all i see are calls into the os to process the run loop and its observers. There's no gecko code on the other side (ie, the action fired by the timer). It's always thread 0 that's running "out of control", so it's probably not java.
I have also seen the behaviour in comment 14, but in my case it was brought on by restarting Camino after a crash, and looking at URLs from the history. I could alleviate it by pasting the same URL into the Location box. I am still on the Beta from 2004051715 (v0.8b)
Created attachment 150191 [details] Trace file from Sampler application I don't konw if this could be helpful. In case not, sorry for the spam ;-)
Thanks Mina. Unfortunately, there's again nothing obvious causing the CPU activity. Could you (or someone) take another sample when Camino isn't doing anything and *not* using lots of CPU, just for comparison? Maybe that will help us see something.
I see a bunch of Java stuff in these samples. Turn Java off, and see if you still get high CPU usage.
Mina, thanks again. I've gone through both samples thread by thread, and I can't find *anything* that's happening in the sample from a spike period that isn't happening identically or with no appreciable difference in the 'good' idle sample. Since it doesn't seem to be anything we are doing, and other Cocoa apps are showing the same or similar behavior, I think we should assume for now that this is an OS bug/behavior. I would suggest we push this off the 0.8 list, and maybe lower the severity (since this is neither a dataloss bug or a chrasher bug, critical seems excessive).
still not enough info to fix, pushing to 0.9
Target Milestone: Camino0.8 → Camino0.9
Created attachment 152517 [details] Another sample taken while Camino (0.9beta) ate CPU cycles as hell. Sample taken at the 4th of July (just coincidence :-) with one of the more recent nightly builds of Camino.
Created attachment 156525 [details] Activity Monitor sample taken from Camino (2004071808 (v0.8+)) while succing CPU cycles. Again a sample which seems to be different from the previous one. A guess would be that it has to do with multiple displays being or not being connected at wakeup - at least that was one of the minor changes I made to my system during the last few days and it happenend twice to me since yesterday. Taken with 2004071808 (v0.8+).
My hunch is that this bug is caused by the event processing timer hack in nsToolkit. I think we should just fix PLevents, and remove the timer hack. We could convert plevents to use CFMachMessages, rather than Carbon Events. That might be more performant.
Just to bump this, I'm using the 2004110908 (v0.8+) nightly on OSX 10.3.6 and am getting this problem fairly often. I don't have any specific data (I'll try to do the Sampler thing next time it happens) but the last occurance was with one window and about 7 tabs and one download. I thought it was related to the download, but when the download finished the high cpu usage continued (by high, I mean pretty much maxed out). This wouldn't be a huge issue but Camino runs very sluggishly when this usage is happening. Please take another look at this bug, as it's a huge inconvenience and one of the main reasons I'm not using Camino as my main browser.
It happened again, this time while running Camino, Firefox 1.0, and Safari. Interestingly enough, suddenly Camino and Firefox were fighting for CPU, each using around 40%. Camino was unresponsive, which firefox still scrolled ok. I quit Firefox, and Camino's usage jumped to around 85%. I took Activity Monitor Samples of both Firefox and Camino while they were battleing for CPU, and of Camino after I quit Firefox, and can upload them if they would be useful.
Created attachment 166730 [details] Sample on G5 Mac OS 10.3.6, latest camino nightly I just thought another sample may help out. I've seen the CPU problem happen a couple times on AdiumX also, but it mostly happens to Camino.
Attachment #166730 - Attachment description: Sample on G5 Mac OS 10.3.6 → Sample on G5 Mac OS 10.3.6, latest camino nightly
Firefox was also using high CPU ... but when I opened Camino on top of that, the whole system locked up. The mouse moved around and the system would sleep and wake up, but nothing else could be activated, not even Force-Quit via cmd-opt-escape.
I've heard reports of this being fixed after bug 271050 was fixed. For those who see this, please try recent trunk builds.
(In reply to comment #34) > I've heard reports of this being fixed after bug 271050 was fixed. > For those who see this, please try recent trunk builds. Mac OS X 10.2.6 (6L60) 512 MB PowerBook G4 500 MHz (version = 11.3) O.K. I posted a tiny comment earlier, though I suspect that I have seen most of the problems mentioned here. I have also briefly reviewed Bug 271050 , and I note that it is extremely difficult to give subjective comments that are useful. Having used Camino 2005011508 after a restart this morning, I would say that I have not seen a beach ball when switching tabs or windows, though Camino can use a high proportion of CPU (in top) when it is busy (or many tabs are open) its usage drops below 3% and sometimes shows as 0.0% when it is quiescent. Nothing has happened like Comments 33 31 30 30 20 16 14 . My vote is positive, but it seems that any subjective report should be taken with a pinch of salt. I will certainly post if I see any problems.
(In reply to comment #35) > I will certainly post if I see any problems. When I opened 9 tabs in one window (from the bookmarks bar) Camino beachballed and CPU usage went to around 50% (I am compiling Firefox at the moment), quite possibly taking all the CPU it can, but the application soon recovered, and at the moment, whilst typing into this form, CPU usage shows as 0%. Jaguar can readily be persuaded to beach ball - whilst waiting for the network, whilst paging back from disk or whilst waiting for the disk - so again, this has to be subjective, but after 9 hours up, Camino seems to be very quick to relinquish the CPU, far more so that the release version, though I have to admit that I often left that running for several weeks. I will try again, and get some precise timings.
since we rewrote the event system entirely, I'm going to mark this as fixed until someone can prove otherwise with a build after we switched to CFRunLoop.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Looks really good, Mike. I have been using the heck out of Camino for over a year, and have had it grab everything available many times, but since the 15JAN nightly the excessive CPU usage of yore certainly appears to have been killed. :o) Thanks!!!!!
You need to log in before you can comment on or make changes to this bug.