Closed Bug 192642 Opened 23 years ago Closed 21 years ago

Excessive CPU usage by Camino, even while it's the background app

Categories

(Camino Graveyard :: General, defect)

Product:
Camino Graveyard
Component:
General
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Camino0.9

People

(Reporter: mikezornek, Assigned: mikepinkerton)

References

Details

Attachments

(6 files)

ThreadViewer data for Navigator sucking CPU
75.26 KB, image/png
Details
Trace file from Sampler application
145.77 KB, application/octet-stream
Details
Trace file when normal CPU usage
205.58 KB, application/octet-stream
Details
Another sample taken while Camino (0.9beta) ate CPU cycles as hell.
3.10 KB, text/plain
Details
Activity Monitor sample taken from Camino (2004071808 (v0.8+)) while succing CPU cycles.
10.27 KB, text/plain
Details
Sample on G5 Mac OS 10.3.6, latest camino nightly
40.26 KB, text/plain
Details
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.
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.
Blocks: 224615
After not having seen this effect for a few months it showed up now. I used the new sample functionality of the Activity Monitor of OSX 10.3. Here is the result. Perhaps someone can read something interesting from it. Ah, it happenend with NO windows open, I openend an empty window while sampling but thats all. Java is OFF, Javascript and Plugins ON. Analysis of sampling pid 619 every 10.000000 milliseconds Call graph: 249 Thread_110b 249 start 249 _start 249 NSApplicationMain 249 -[NSApplication run] 249 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 249 _DPSNextEvent 249 BlockUntilNextEventMatchingListInMode 249 ReceiveNextEventCommon 249 RunCurrentEventLoopInMode 249 CFRunLoopRunSpecific 248 __CFRunLoopRun 235 mach_msg 235 mach_msg_trap 235 mach_msg_trap 7 __CFRunLoopDoObservers 3 CFArraySortValues 3 __CF_FAULT_CALLBACK 3 _dyld_image_containing_address 3 _dyld_image_containing_address 3 _dyld_get_image_header_containing_address 2 _dyld_get_image_header_containing_address 1 set_lock 1 dyld_mach_thread_self 1 clear_lock 1 clear_lock 3 CFSetApplyFunction 2 __CF_FAULT_CALLBACK 2 _dyld_image_containing_address 2 _dyld_image_containing_address 2 _dyld_get_image_header_containing_address 2 _dyld_get_image_header_containing_address 1 __CFRunLoopCollectObservers 1 __CFRunLoopCollectObservers 1 CFRelease 1 __CFArrayDeallocate 1 __CFArrayReleaseValues 1 __CF_INVOKE_CALLBACK 1 __CF_INVOKE_CALLBACK 4 __CFRunLoopModeFindSourceForMachPort 4 CFSetApplyFunction 2 __CFRunLoopFindSource 2 __CFRunLoopFindSource 1 CFMachPortGetPort 1 CFMachPortGetPort 1 __CF_FAULT_CALLBACK 1 _dyld_image_containing_address 1 _dyld_image_containing_address 1 _dyld_get_image_header_containing_address 1 _dyld_get_image_header_containing_address 1 __CFRunLoopDoTimer 1 __CFRunLoopDoTimer 1 __NSFireTimer 1 saveFP 1 saveFP 1 0x9022a80c 1 0x9022a80c 249 Thread_1203 249 _pthread_body 249 __ape_agent 249 __ape_internal 249 mach_msg 249 mach_msg_trap 249 mach_msg_trap 249 Thread_1303 249 _pthread_body 249 _pt_root 249 nsThread::Main(void*) 249 nsSocketTransportService::Run() 249 _pr_poll_with_poll 249 poll 249 select 249 select 249 Thread_1403 249 _pthread_body 249 _pt_root 249 nsThread::Main(void*) 249 TimerThread::Run() 249 PR_WaitCondVar 249 pt_TimedWait 249 _pthread_cond_wait 249 semaphore_timedwait_signal_trap 249 semaphore_timedwait_signal_trap 249 Thread_1503 249 _pthread_body 249 forkThreadForFunction 249 -[NSUIHeartBeat _heartBeatThread:] 249 -[NSConditionLock lockWhenCondition:] 249 _pthread_cond_wait 249 semaphore_wait_signal_trap 249 semaphore_wait_signal_trap 249 Thread_1603 249 _pthread_body 249 __CFSocketManager 249 select 249 select 249 Thread_1703 249 _pthread_body 249 CAPThread::Entry(CAPThread*) 249 HALRunLoop::OwnThread(void*) 249 CFRunLoopRunSpecific 249 __CFRunLoopRun 249 mach_msg 249 mach_msg_trap 249 mach_msg_trap 249 Thread_1803 249 _pthread_body 249 _pt_root 249 nsIOThreadPool::ThreadFunc(void*) 249 PR_WaitCondVar 249 pt_TimedWait 249 _pthread_cond_wait 249 semaphore_timedwait_signal_trap 249 semaphore_timedwait_signal_trap Total number in stack (recursive counted multiple, when >=5): 7 _pthread_body 6 _dyld_image_containing_address Sort by top of stack, same collapsed (when >= 5): mach_msg_trap 733 select 498 semaphore_timedwait_signal_trap 498 semaphore_wait_signal_trap 249 _dyld_get_image_header_containing_address 5 Sample analysis of process 619 written to file /dev/stdout Sampling process 619 each 10 msecs 300 times
This is probably related to bug #227680.
Severity: normal → critical
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)
I've seen this on occasion, and the 05-17 0.8b just did it to me for the first time. Only two apps running (mail.app and Camino), and only one simple page open in Camino - mostly text and a few images, no Javascript. System is OS X 10.3.4 Camino had been running very nicely for several hours with occasional system sleeps. Suddenly CPU usage shot up and Camino was taking 86% of my 1GHz G4. I looked at the console and there was nothing at all unusual, I killed the only open Camino window - no change, opened new Camino window - no change, quit Camino and CPU went back to near zero immediately. Launched Camino: Everything just fine. Opened same web page, no CPU load plateau. Not much to go on. Sorry I couldn't be of more help. Tom
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.
Here it is, Stuart !
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
Sample taken at the 4th of July (just coincidence :-) with one of the more recent nightly builds of Camino.
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.
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
Closed: 21 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!!!!!
No longer blocks: 224615
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: