Last Comment Bug 781732 - Severe jank in nsWindowsSystemProxySettings::getPACURI
: Severe jank in nsWindowsSystemProxySettings::getPACURI
Status: RESOLVED FIXED
[Snappy]
:
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: Trunk
: x86_64 Windows 7
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
: 784586 (view as bug list)
Depends on: 769764 787757
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-09 20:58 PDT by Gregory Szorc [:gps]
Modified: 2013-04-09 06:16 PDT (History)
13 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
profile output (323.16 KB, text/plain)
2012-08-09 20:58 PDT, Gregory Szorc [:gps]
no flags Details
Profile with similar system calls, but from back button (403.85 KB, text/plain)
2012-08-09 21:20 PDT, Gregory Szorc [:gps]
no flags Details

Description Gregory Szorc [:gps] 2012-08-09 20:58:37 PDT
Created attachment 650775 [details]
profile output

I experienced severe jank (30+s) in nsProtocolProxyService when an open tab was on a Jenkins web site. The attached patch is the output from the SPS profiler on official builds of Nightly 2012-08-09 on Windows 7.

All the jank appears to be inside core win32 dlls. The last Firefox API is ReadInternetOption(). This is called by nsWindowSystemProxyService::getPACURI, which is called by nsProtocolProxyService::resolve*. It all chains up to an nsXMLHttpRequest::Open.

My computer (Core i7 2600K) was under heavy load at the time this happened. But, the rest of my Windows UI was responsive while Firefox was non-responsive. When I have the Jenkins tab open, jank occurs with regular frequency (I'm pretty sure it is related to a repeating timer on the web site). I'm not sure if the HTML is doing something really dumb (tm). But, I would expect it to not cause jank if waiting on a system call that could take 30+s.

The computer I'm experiencing this on was recently moved to a new network. I suspect this plus FoxyProxy might be causing some weirdness.
Comment 1 Gregory Szorc [:gps] 2012-08-09 21:01:17 PDT
s/nsWindowsSystemProxyService/nsWindowsSystemProxySettings/. Lack of copy + paste in the profiler UI plus a few beers is not a good combination.
Comment 2 Gregory Szorc [:gps] 2012-08-09 21:04:39 PDT
I have FoxyProxy installed, but I have it disabled through the FoxyProxy UI ("Completely disable FoxyProxy" option).
Comment 3 Gregory Szorc [:gps] 2012-08-09 21:20:05 PDT
Created attachment 650783 [details]
Profile with similar system calls, but from back button

This profile shows the same jank behavior and similar call stack. The only difference is it chains up to hitting the back button in the browser, not some XMLHttpRequest from content.
Comment 4 Josh Aas 2012-08-09 22:58:40 PDT
I think Patrick McManus is working on related issues right now. See bug 767159 and bug 769764.
Comment 5 Patrick McManus [:mcmanus] 2012-08-10 07:03:38 PDT
Thanks :gps - Josh is right that 769764 has grown from its original scope of just DNS jank to also include the jank you report here. Its a tricky thing to solve.

769764 will resolve it for all cases except plugins, which are covered in 778201.

I'm actually not sure what this means for FoxyProxy - I'll have to add that to my todo list to look into.
Comment 6 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2012-08-10 09:36:18 PDT
Roc and I were seeing something similar in an earlier bug, but that was supposed to be fixed.
Comment 7 Patrick McManus [:mcmanus] 2012-08-10 13:41:53 PDT
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #6)
> Roc and I were seeing something similar in an earlier bug, but that was
> supposed to be fixed.

you are probably thinking of 235853.. the patch for that bug

*] didn't try and fix the whole problem
*] didn't actually fix any of the parts it did try to solve
*] caused other regressions

it was backed out :)
Comment 8 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2012-08-10 13:48:53 PDT
No, I was thinking of bug 774242.
Comment 9 Patrick McManus [:mcmanus] 2012-08-22 05:35:22 PDT
*** Bug 784586 has been marked as a duplicate of this bug. ***
Comment 10 Gregory Szorc [:gps] 2012-08-24 11:55:16 PDT
FWIW, I worked around this by changing my default network settings from "Use system proxy settings" to "No proxy."
Comment 11 Josh Aas 2012-11-20 03:07:06 PST
Is this still a problem? Seems like it should be resolved, so marking this as fixed, reopen if I'm wrong.
Comment 12 Gregory Szorc [:gps] 2012-11-20 10:38:11 PST
The problem seems to have gone away with all the async proxy rewrite stuff from a few months back.
Comment 13 Vladan Djeric (:vladan) 2013-04-08 21:11:48 PDT
I'm seeing quite a few of these stacks in Telemetry chrome-hang data from Nightly 22. Is there another bug for this?

InternetGetConnectedStateExW (in wininet.pdb)
ReadInternetOption (in xul.pdb)
nsWindowsSystemProxySettings::GetPACURI(nsACString_internal &) (in xul.pdb)
nsProtocolProxyService::PrefsChanged(nsIPrefBranch *,char const *) (in xul.pdb)
nsProtocolProxyService::Init() (in xul.pdb)
nsProtocolProxyServiceConstructor (in xul.pdb)
mozilla::GenericFactory::CreateInstance (in xul.pdb)
nsComponentManagerImpl::CreateInstanceByContractID (in xul.pdb)
nsComponentManagerImpl::GetServiceByContractID (in xul.pdb)
nsCOMPtr_base::assign_from_gs_contractid_with_error(in xul.pdb)
mozilla::net::nsHttpChannel::ResolveProxy() (in xul.pdb)
mozilla::net::nsHttpChannel::AsyncOpen (in xul.pdb)
nsURILoader::OpenURI (in xul.pdb)
nsDocShell::DoChannelLoad(nsIChannel *,nsIURILoader *,bool) (in xul.pdb)
nsDocShell::DoURILoad(nsIURI *,nsIURI *,bool,nsISupports *,char const *,nsAString_internal const &,nsIInputStream *,nsIInputStream *,bool,nsIDocShell * *,nsIRequest * *,bool,bool,bool) (in xul.pdb)
Comment 14 Patrick McManus [:mcmanus] 2013-04-09 06:16:52 PDT
vladan - that is 846914

Note You need to log in before you can comment on or make changes to this bug.