122682 - DNS: Offline: browser hangs temporarily if switched offline while DNS thread is inside gethostbyname

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[Darin Fisher]

browser hangs temporarily if switched offline while DNS thread is inside
gethostbyname.  if your system is having trouble connecting to the DNS server,
then this can cause the browser to hang until gethostbyname times out.  very bad!

Comment 1

[gordon]

The DNS service Shutdown() method should just mark it "offline" and there should
be a private shutdown method that can be called from the destructor.

Comment 2

[gordon]

Attachment: Propose patch. Darin, will this suit you?

Comment 3

[gordon]

Comment on attachment 69584 [details] [diff] [review]
Propose patch.  Darin, will this suit you?

sr=darin

Comment 4

[Gagan]

Comment on attachment 69584 [details] [diff] [review]
Propose patch.  Darin, will this suit you?

r=gagan

Comment 5

[gordon]

Patch checked in.  Marking FIXED.

Comment 6

[benc]

Darin: is there a set of steps you want me to run on allplats, or can you verify
this as code change?

Comment 7

[Darin Fisher]

benc:

if you have a slow connection to your DNS server, then you should be able to
verify this.

1) load page that takes a long time to resolve
2) press offline button
3) verify that UI is still responsive

Comment 8

[benc]

So, by "inside gethostbyname()", you mean going offline before the DNS response
returns? I think I can get a working testcase. Do you want just a Linux
verification?

Comment 9

[Darin Fisher]

yup.. that's what i meant.. and yes, only a linux testcase :)

Comment 10

[benc]

VERIFIED/FIXED:

darin: I found that the browser does not hang, although the throbber does
continue to run after going offline. (Not surprisingly, it does ignore the error
returned from the DNS server after going offline...

Otherwise, the offline and return to online behavior seems fine.

I don't know if the throbber ever stops in this state, I've left it running
while I go to a meeting. If this does loop forever, I'll file a new bug later,
and note it here.

---
It took a while to find a query that would reliably hang open so I could
reproduce this. The problem is that I wanted a query that would always hang
open, again and again, but nameserver caching has a tendency to cause even the
slowest query to return faster and faster as the upstream systems learn to adapt
to my pestering.

what I did, was use hardtoreach.cr.yp.to, which is (for you DNS buffs out
there...) a NS entry that points to a non-existent DNS server. Lame delegation
is not an error cached by DNS servers, so this takes a long time to error.