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



Camino Graveyard
16 years ago
14 years ago


(Reporter: Mike Zornek, Assigned: Mike Pinkerton (not reading bugmail))


Mac OS X



(6 attachments)



16 years ago
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:


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.

Comment 1

16 years ago
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.

Comment 2

16 years ago
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.


16 years ago
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

Comment 3

16 years ago
*** Bug 169993 has been marked as a duplicate of this bug. ***

Comment 4

15 years ago
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

Comment 5

15 years ago
I think I still see this now and again.

Comment 6

15 years ago
Me too. In addition I now have a normal production machine with no wonky
firmware and it still shows up infrequently.


15 years ago
Blocks: 224615

Comment 7

15 years ago
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

Comment 8

15 years ago
This is probably related to bug #227680.


15 years ago
Severity: normal → critical

Comment 9

15 years ago
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.

Comment 10

15 years ago
I just saw this for the first time ever with my own build from 2004022616. Its
still here.

Comment 11

14 years ago
I had it yesterday and it was eating up 75% cpu!


14 years ago
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

Comment 12

14 years ago
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.


Comment 13

14 years ago
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:


I haven't seen this behaviour in Camino or iTerm during the last few weeks (I'm
running OSX 10.3.3)

Comment 14

14 years ago
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.

Comment 15

14 years ago
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

Comment 16

14 years ago
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.

Comment 17

14 years ago
We really need to see Sampler or ThreadViewer data for periods of CPU suckage to
figure this out.

Comment 18

14 years ago
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.

Comment 19

14 years ago
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)

Comment 20

14 years ago
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.


Comment 21

14 years ago
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 ;-)

Comment 22

14 years ago
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.

Comment 23

14 years ago
Created attachment 150204 [details]
Trace file when normal CPU usage

Here it is, Stuart !

Comment 24

14 years ago
I see a bunch of Java stuff in these samples. Turn Java off, and see if you
still get high CPU usage.

Comment 25

14 years ago
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).

Comment 26

14 years ago
still not enough info to fix, pushing to 0.9
Target Milestone: Camino0.8 → Camino0.9

Comment 27

14 years ago
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.

Comment 28

14 years ago
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+).

Comment 29

14 years ago
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.

Comment 30

14 years ago
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

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.

Comment 31

14 years ago
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.

Comment 32

14 years ago
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.


14 years ago
Attachment #166730 - Attachment description: Sample on G5 Mac OS 10.3.6 → Sample on G5 Mac OS 10.3.6, latest camino nightly

Comment 33

14 years ago
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

Comment 34

14 years ago
I've heard reports of this being fixed after bug 271050 was fixed. For those who see this, please try 
recent trunk builds.

Comment 35

14 years ago
(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.

Comment 36

14 years ago
(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.


Comment 37

14 years ago
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.
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 38

14 years ago
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)



14 years ago
No longer blocks: 224615
You need to log in before you can comment on or make changes to this bug.