Closed
Bug 774242
Opened 12 years ago
Closed 12 years ago
Firefox unusable due to constant janking in wininet.dll!IsWpadEnabledForConnectedNetworks innsWindowsSystemProxySettings::GetProxyForURI
Categories
(Core :: Networking, defect)
Tracking
()
RESOLVED
FIXED
mozilla16
Tracking | Status | |
---|---|---|
firefox16 | - | --- |
People
(Reporter: roc, Unassigned)
References
Details
Just now my Firefox build was unusable due to constant hangs. I attached a debugger and did "Break All" many times as a sort of poor-man's profiling. The main thread was constantly stuck at the following stack: ntdll.dll!_NtWaitForSingleObject@12() + 0x15 bytes ntdll.dll!_NtWaitForSingleObject@12() + 0x15 bytes kernel32.dll!_QueueUserWorkItem@12() + 0x14 bytes kernel32.dll!_WaitForSingleObjectExImplementation@12() + 0x43 bytes kernel32.dll!_WaitForSingleObject@8() + 0x12 bytes wininet.dll!IsWpadEnabledForConnectedNetworks() + 0x8d bytes wininet.dll!QueryPerConnOptions() + 0x24f6a bytes wininet.dll!_InternetQueryOptionA@16() + 0x37572 bytes wininet.dll!_InternetQueryOptionW@16() + 0x94d5 bytes > xul.dll!ReadInternetOptionInt(unsigned int aOption, unsigned int & aValue) Line 90 + 0x26 bytes C++ xul.dll!nsWindowsSystemProxySettings::GetProxyForURI(nsIURI * aURI, nsACString_internal & aResult) Line 313 + 0x27 bytes C++ xul.dll!nsProtocolProxyService::Resolve_Internal(nsIURI * uri, const nsProtocolInfo & info, unsigned int flags, bool * usePAC, nsIProxyInfo * * result) Line 1255 C++ xul.dll!nsProtocolProxyService::Resolve(nsIURI * uri, unsigned int flags, nsIProxyInfo * * result) Line 830 C++ xul.dll!nsIOService::LookupProxyInfo(nsIURI * aURI, nsIURI * aProxyURI, unsigned int aProxyFlags, nsCString * aScheme, nsIProxyInfo * * outPI) Line 599 + 0x30 bytes C++ xul.dll!nsIOService::NewChannelFromURIWithProxyFlags(nsIURI * aURI, nsIURI * aProxyURI, unsigned int aProxyFlags, nsIChannel * * result) Line 643 C++ xul.dll!nsIOService::NewChannelFromURI(nsIURI * aURI, nsIChannel * * result) Line 577 C++ Needless to say, we call NewChannelFromURI *a lot* (in my case, I saw a ton of XHR::Opens, probably from Gmail and other apps, but there were other callers too). I don't have any way to measure the distribution of pause times associated with these ReadInternetOptionInt calls, but some of them seem to be multiple seconds per call. I haven't seen this before. There are two potential changes in my environment that could be related: -- I've just started using the wired network at the hotel. Maybe this network, or something on it, is making IsWpadEnabledForConnectedNetworks super slow? However, when I started my laptop on this network for the first time this morning, things were OK. -- However, soon after that I finished installing some Windows security updates and rebooted to let those updates take effect. I only saw this problem after those updates took effect. These are the updates I installed: Security Update for Windows 7 for x64-based Systems (KB2698365) Cumulative Security Update for Internet Explorer 9 for Windows 7 for x64-based Systems (KB2719177) Windows Malicious Software Removal Tool x64 - July 2012 (KB890830) Security Update for Windows 7 for x64-based Systems (KB2655992) Security Update for Windows 7 for x64-based Systems (KB2691442) Security Update for Windows 7 for x64-based Systems (KB2719985) Security Update for Windows 7 for x64-based Systems (KB2718523) Definition Update for Microsoft Security Essentials - KB2310138 (Definition 1.129.1744.0) Kyle says this may be related to bug 766280. This is an ultra-critical bug; it will force users to use another browser if they can find one that isn't affected by this bug (I didn't check).
See also https://bugzilla.mozilla.org/show_bug.cgi?id=766280#c3 I only managed to catch it in the debugger once.
Comment 2•12 years ago
|
||
> xul.dll!ReadInternetOptionInt(unsigned int aOption, unsigned int & aValue) Line 90 + 0x26 bytes C++ This function was renamed by bug 771115. Is this bug reproducible on the latest build?
Reporter | ||
Comment 3•12 years ago
|
||
I think this was fixed by bug 771115.
Comment 4•12 years ago
|
||
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #3) > I think this was fixed by bug 771115. Found in 16, fixed in 16.
Updated•12 years ago
|
status-firefox16:
affected → ---
Target Milestone: --- → mozilla16
You need to log in
before you can comment on or make changes to this bug.
Description
•