327452 - camino hangs on launch (favicons loading before PAC)

Status: VERIFIED WORKSFORME

(Camino Graveyard :: General, defect)

Description

[Lawrence Paulson]

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

Comment 1

[Ludovic Hirlimann [:Usul]]

lawrence could you give us your OS version # ?

Are you behind a firewall/proxy ? if so what kind of proxy ?

Comment 2

[Lawrence Paulson]

Attachment: system profile in bzipped xml format

Comment 3

[Lawrence Paulson]

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.

Comment 4

[Lawrence Paulson]

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.

Comment 5

[Lawrence Paulson]

I notice that upon launch the Console log reports

"2006-02-24 11:32:28.984 Camino[11997] 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.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Simon, could a slow or misconfigured proxy server cause this sort of thing?

Comment 7

[Simon Fraser [no longer active]]

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.

Comment 8

[Lawrence Paulson]

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.

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(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....

Comment 10

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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)....

Comment 11

[Lawrence Paulson]

I'm happy to say that the hanging bug seems to be gone.

Just as well, because I've been having problems with Safari.

Comment 12

[froodian (Ian Leue)]

Closing WFM since this doesn't seem to be occuring for the reporter any more.