User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/417.9 (KHTML, like Gecko) Safari/417.8 Build Identifier: Camino 1.0 (new release) Camino hangs upon launch, or limps along for a few links, but before very long the beachball is permanent. I have deleted past preference files, Fullcircle directory, etc. Reproducible: Always Steps to Reproduce: 1. launch camino 2. attempt to open any page 3. Analysis of sampling pid 25110 every 10.000000 milliseconds Call graph: 283 Thread_0f0f 283 start 283 start 283 NSApplicationMain 283 -[NSApplication run] 283 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 283 _DPSNextEvent 283 BlockUntilNextEventMatchingListInMode 283 ReceiveNextEventCommon 283 RunCurrentEventLoopInMode 283 CFRunLoopRunSpecific 283 __CFRunLoopRun 283 __CFRunLoopDoTimer 283 __NSFireDelayedPerform 283 NeckoCacheHelper::GetCanonicalPageURI(nsACString_internal const&, nsACString_internal&) 283 RemoteURILoadManager::CancelAllRequests() 283 RemoteURILoadManager::RequestURILoad(nsAString_internal const&, objc_object*, objc_object*, objc_object*, int) 283 txFormatNumberFunctionCall::FORMAT_QUOTE 283 nsIOService::NewChannelFromURI(nsIURI*, nsIChannel**) 283 nsProtocolProxyService::Resolve(nsIURI*, unsigned, nsIProxyInfo**) 283 nsPACMan::GetProxyForURI(nsIURI*, nsACString_internal&) 283 SharedStub 283 PrepareAndDispatch 283 nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, nsXPTMethodInfo const*, nsXPTCMiniVariant*) 283 js_Invoke 283 js_Interpret 283 js_Invoke 283 XPC_WN_CallMethod(JSContext*, JSObject*, unsigned, long*, long*) 283 XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) 283 _XPTC_InvokeByIndex 283 nsDNSService::Resolve(nsACString_internal const&, unsigned, nsIDNSRecord**) 283 PR_Wait 283 PR_WaitCondVar 283 pthread_cond_wait 283 semaphore_wait_signal_trap 283 semaphore_wait_signal_trap 283 Thread_1003 283 _pthread_body 283 PR_Select 283 nsThread::Main(void*) 283 nsSocketTransportService::Run() 283 nsSocketTransportService::Poll(unsigned*) 283 PR_OpenDir 283 poll 283 select 283 select 283 Thread_1103 283 _pthread_body 283 PR_Select 283 nsThread::Main(void*) 283 TimerThread::Run() 283 PR_WaitCondVar 283 PR_Unlock 283 pthread_cond_timedwait 283 semaphore_timedwait_signal_trap 283 semaphore_timedwait_signal_trap 283 Thread_1203 283 _pthread_body 283 PR_Select 283 nsHostResolver::ThreadFunc(void*) 283 PR_GetAddrInfoByName 283 getaddrinfo 283 gai_lookupd 283 _lookup_all 283 _lookup_all_secure 283 mach_msg 283 mach_msg_trap 283 mach_msg_trap 283 Thread_1303 283 _pthread_body 283 __CFSocketManager 283 select 283 select 283 Thread_1403 283 _pthread_body 283 forkThreadForFunction 283 -[NSUIHeartBeat _heartBeatThread:] 283 -[NSConditionLock lockWhenCondition:] 283 pthread_cond_wait 283 semaphore_wait_signal_trap 283 semaphore_wait_signal_trap Total number in stack (recursive counted multiple, when >=5): 5 _pthread_body Sort by top of stack, same collapsed (when >= 5): select 566 semaphore_wait_signal_trap 566 mach_msg_trap 283 semaphore_timedwait_signal_trap 283 Sample analysis of process 25110 written to file /dev/stdout Sampling process 25110 each 10 msecs 300 times
lawrence could you give us your OS version # ? Are you behind a firewall/proxy ? if so what kind of proxy ?
I gave it another go this morning, after upgrading to 10.4.5. Although Camino needed a few minutes to "warm up", it then started working much better. The beachball mainly afflicts the GUI itself, above all when building menues for toolbar bookmarks (even if the menu has only 8 items). But also hovering over a hyperlink can cause the beachball, especially when first launched. Surprising on a dual 2.5GHz G5. However, Camino is *very* fast at responding to requests from other apps, like NetNewsWire Lite: the new windows open instantly. Re firewall: yes, the Computer Lab runs a draconian firewall, but I don't think it's to blame.
I have done more tests and the behaviour is pretty consistent. Upon launch, Camino is extremely sluggish for a couple of minutes. The delays get briefer and briefer and eventually disappear.
I notice that upon launch the Console log reports "2006-02-24 11:32:28.984 Camino Using Proxy Auto-Config (PAC) file http://www.cam.ac.uk/proxyconfig.pac" Could this be to blame? It would explain Camino's becoming responsive after a few minutes.
Simon, could a slow or misconfigured proxy server cause this sort of thing?
Yeah, this look like URL loads for favicons getting stuck because the PAC file hasn't loaded yet; they get stuck in DNS. We had a bug similar to this about the first page load not using PAC, but I couldn't find it.
In the past few days the problem has disappeared. That is, Camino launches promptly and is able to respond immediately. I have no idea what may have changed--certainly it's the same version of Camino.
(In reply to comment #7) > We had a bug similar to this about > the first page load not using PAC, but I couldn't find it. Bug 185644 via bug 100022, but there are a couple of supposedly-fixed proxy bugs that have re-appeared recently (bug 324424, bug 327599), so who knows....
Summary: camino hangs on launch → camino hangs on launch (favicons loading before PAC)
Lawrence, has this bug returned, or are you still getting the good results you reported in comment 8? I ran across bug 188006 tonight looking for something else, and it (as well as the apparent sudden disappearance of the problem) made me wonder if perhaps *part* of the problem in this instance was with the Cambridge proxy server/PAC script. I did some logging in association with another bug, and it seems like we do start trying to issue network requests for many favicons very early; I'm not behind a proxy so I couldn't tell where it might fall (and, well, Necko logs are somewhat Greek to me)....
QA Contact: general
I'm happy to say that the hanging bug seems to be gone. Just as well, because I've been having problems with Safari.
Closing WFM since this doesn't seem to be occuring for the reporter any more.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.