1193796 - Unable to access Google properties with Firefox Nightly

Status: RESOLVED DUPLICATE of bug 1193541

(Core :: Networking, defect)

Description

[Botond Ballo [:botond]]

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.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

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

Comment 2

[Botond Ballo [:botond]]

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)".

Comment 3

[Mike Conley (:mconley) (:⚙️)]

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

Comment 4

[Botond Ballo [:botond]]

Yup, the problem reproduces in Safe Mode.

I should mention that I'm running on Linux (Debian Testing).

Comment 5

[Botond Ballo [:botond]]

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.

Comment 6

[Mike Conley (:mconley) (:⚙️)]

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).

Comment 7

[Andrew Comminos [:acomminos]]

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

Comment 8

[Mike Conley (:mconley) (:⚙️)]

Props.

Comment 9

[Andrew Comminos [:acomminos]]

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.

Comment 10

[Andrew Comminos [:acomminos]]

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

Comment 11

[Mike Conley (:mconley) (:⚙️)]

(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.

Comment 12

[Andrew Comminos [:acomminos]]

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.

Comment 13

[Andrew Comminos [:acomminos]]

ea804beb9ff6 appears to be the first bad changeset. Looking into it.

https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=ea804beb9ff6

Comment 14

[Andrew Comminos [:acomminos]]

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

Comment 15

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 16

[Andrew Comminos [:acomminos]]

Can reproduce with mozilla-aurora 42.0a2, build ID 20150812101234. 

Built from https://hg.mozilla.org/releases/mozilla-aurora/rev/bef1e3e26eee.

Comment 17

[Mike Conley (:mconley) (:⚙️)]

[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.

Comment 18

[Patrick McManus [:mcmanus]]

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

Comment 19

[Patrick McManus [:mcmanus]]

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.

Comment 20

[Daniel Stenberg [:bagder]]

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.

Comment 21

[Daniel Stenberg [:bagder]]

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

Comment 22

[Botond Ballo [:botond]]

Attachment: logging with NSPR_LOG_MODULES=timestamp,nsNotifyAddr:5

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

Comment 23

[Daniel Stenberg [:bagder]]

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

Comment 26

[znmeb]

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.