STR: 1. Go to https://sso.mozilla.com/gmail 2. Enter password and log in Expected results: You are successfully logged in. Actual results: You're stuck on the "Signing in to Google Apps (mozilla.com)" screen forever. This issue is preventing me from accessing my email with Nightly; I had to switch to Developer Edition to access it.

Are you able to sign in in a non-e10s window?

In a non-e10s window, the behaviour is even more strange: I get stuck on a blank grey screen that doesn't even have the message "Signing in to Google Apps (mozilla.com)".

I'm not able to reproduce this on Nightly. Can you attempt to reproduce in Safe Mode? (Help > Restart with Add-ons Disabled).

Yup, the problem reproduces in Safe Mode. I should mention that I'm running on Linux (Debian Testing).

Mike and I investigated this a bit - the hanging is caused by a request to google.com never getting a response. In fact, Google websites like google.com or youtube.com fail to load altogether. Andrew Comminos and Andrew Overholt are also able to reproduce this problem, and they're running Linux as well.

One of these group is currently looking for a regression window. needinfo'ing botond for now on getting that (unless he's handed off regression hunting to someone else).

I'll take a look at finding the regression window, I can reproduce consistently and am no longer eating lunch.

Props.

This is as far as I could get with mozregression; Last good revision: 1639af64e372 First bad revision: 51ebb22f97a0 https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=91de9c670800&tochange=24f4d8e5e24b The issue started with 2015-08-08's nightly.

Sorry, wrong pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1639af64e372&tochange=51ebb22f97a0

(In reply to Andrew Comminos [:acomminos] from comment #10) > Sorry, wrong pushlog: > https://hg.mozilla.org/integration/mozilla-inbound/ > pushloghtml?fromchange=1639af64e372&tochange=51ebb22f97a0 Did you use mozregression for this? I suspect we can narrow this a bit more if we use mozregression to find which of these pushes to inbound caused this.

mozregression claims couldn't bisect any further in this range; > 0:00.26 LOG: MainThread Bisector INFO Getting inbound builds between 1639af64e372 and 51ebb22f97a0 > 0:06.18 LOG: MainThread Bisector INFO Oh noes, no (more) inbound revisions :( > 0:06.18 LOG: MainThread Bisector INFO Last good revision: 1639af64e372 > 0:06.18 LOG: MainThread Bisector INFO First bad revision: 51ebb22f97a0 I can dig through the inbound builds manually in this range for anything suspicious.

ea804beb9ff6 appears to be the first bad changeset. Looking into it. https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=ea804beb9ff6

Reverting fea6620f36b8, the fix for bug 1191253, fixes the issue on my local build.

Bug 1191253 got landed for 42, so this is probably on dev edition now. acomminos - do you have the cycles to confirm with last nights mozilla-aurora build? If so, we should definitely track this for 42.

Can reproduce with mozilla-aurora 42.0a2, build ID 20150812101234. Built from https://hg.mozilla.org/releases/mozilla-aurora/rev/bef1e3e26eee.

[Tracking Requested - why for this release]: Still unclear what's going wrong here, but the user impact is that this appears to break connections to (at least) Google properties for some network configurations for Linux users.

I'm going to call this a broad dup (in the sense that 1191253 caused regressions) of 1193541

fwiw I'm running linux 64 nightlies and don't have this problem - but its on a desktop without sleep events, so that might be relevant.

I too run 64bit linux without seeing this problem, but I'll run more experiments to see what I can do to force it to trigger and dig deeper.

This said, it'd be very interesting and educational to get some logging from such a problematic case, especially from the "nsNotifyAddr" module.

Here is the log I got with "NSPR_LOG_MODULES=timestamp,nsNotifyAddr:5" while trying to load "google.com" in an affected build.

Thanks! Ouch, what an awful rate of activities there that I really cannot explain easily. I can see the need for some additional logging to figure out what's going on. Let's continue this in bug 1193541

I've got a bit more info in bug 1194940. I've got one machine with Debian testing 64 bit that works (laptop on WiFi) and one that doesn't (workstation, wired). Both have Docker installed, which does things to networking. I can back out Docker and retest.