The default bug view has changed. See this FAQ.

Severe jank in nsWindowsSystemProxySettings::getPACURI

RESOLVED FIXED

Status

()

Core
Networking: HTTP
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: gps, Unassigned)

Tracking

Trunk
x86_64
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Snappy])

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
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.
(Reporter)

Comment 1

5 years ago
s/nsWindowsSystemProxyService/nsWindowsSystemProxySettings/. Lack of copy + paste in the profiler UI plus a few beers is not a good combination.
(Reporter)

Comment 2

5 years ago
I have FoxyProxy installed, but I have it disabled through the FoxyProxy UI ("Completely disable FoxyProxy" option).
(Reporter)

Comment 3

5 years ago
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

5 years ago
I think Patrick McManus is working on related issues right now. See bug 767159 and bug 769764.
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.
Depends on: 769764, 778201
Roc and I were seeing something similar in an earlier bug, but that was supposed to be fixed.
(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 :)
No, I was thinking of bug 774242.
Duplicate of this bug: 784586
(Reporter)

Comment 10

5 years ago
FWIW, I worked around this by changing my default network settings from "Use system proxy settings" to "No proxy."
No longer depends on: 778201
Depends on: 787757

Comment 11

4 years ago
Is this still a problem? Seems like it should be resolved, so marking this as fixed, reopen if I'm wrong.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
(Reporter)

Comment 12

4 years ago
The problem seems to have gone away with all the async proxy rewrite stuff from a few months back.
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)
vladan - that is 846914
You need to log in before you can comment on or make changes to this bug.