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)

x86_64
Windows 7
defect
Not set
normal

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).
>	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?
I think this was fixed by bug 771115.
Status: NEW → RESOLVED
Closed: 12 years ago
Depends on: 771115
Resolution: --- → FIXED
(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.
Target Milestone: --- → mozilla16
You need to log in before you can comment on or make changes to this bug.