Closed Bug 192642 Opened 22 years ago Closed 20 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: 20 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: