729343 - Nightly sometimes just stops being able to connect to google.com

Status: RESOLVED DUPLICATE of bug 739522

(Core :: Networking: HTTP, defect)

Description

[:Gavin Sharp [email: [e-mail]]]

My Nightly build sometimes just stops being able to connect to Google web properties. I can load other websites in that browser instance just fine, and loading Google in another browser also works fine. The symptoms are that trying to load a google page just spins indefinitely and never times out. I have a load of "google.com" that I started in a tab 5 minutes ago, and it's still sitting there spinning.

I suspect that this is a problem specific to SPDY, since Google is the only popular site that makes use of it as far as I know, and other sites/programs aren't affected (I've only ever seen this in Nightly, and it started recently - within the past week, perhaps?).

I've found that toggling "Work Offline" (i.e. ioService.offline) fixes the problem.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

I don't have reliable steps to get into this state, but once I'm in it seems to last indefinitely. I've hit it 3-4 times in the past couple of days. I can try to collect NSPR logging output - do you have any other thoughts on data I can collect that might help?

Comment 2

[Patrick McManus [:mcmanus]]

hi gavin - my best guess is that if this is a known issue at all it would be fixed by 728113, which should be ready to push real soon now.

does a shift reload help? (it might help with 728113 but I'm not 100% certain.)

the NSPR log is clearly the best information we can get.

also netstat output might be interesting while it is happening.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Shift reload of what? :) I don't have any existing Google tabs open, and I can't complete a load of Google in any new tabs.

bug 728113 looks promising, I'll track that.

Comment 4

[Patrick McManus [:mcmanus]]

also, if you set network.http.spdy.timeout to 45 you would probably get (most) of the benefit of 728113 at the cost of having to setup new connections a little more often. could be a way to test the theory.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

Is NSPR_LOG_MODULES=nsHttp:5,nsSocketTransport:5,nsHostResolver:5 sufficient for logging?

Comment 6

[Patrick McManus [:mcmanus]]

(In reply to Gavin Sharp (use [e-mail] for email) from comment #5)
> Is NSPR_LOG_MODULES=nsHttp:5,nsSocketTransport:5,nsHostResolver:5 sufficient
> for logging?

hopefully! (yes, that's what I would use..)

Comment 7

[:Gavin Sharp [email: [e-mail]]]

I had logging enabled for some time, but never managed to see this again.

Comment 8

[Patrick McManus [:mcmanus]]

thanks gavin - I have reason to believe this still exists as a dup of 739522 as a very low probability event.

I've even got a theory on how it could happen (basically syn loss with extremely long timeout during a period when we try and only use 1 SPDY connection).