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!
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.
Target Milestone: --- → mozilla0.9.9
Comment on attachment 69584 [details] [diff] [review] Propose patch. Darin, will this suit you? sr=darin
Attachment #69584 - Flags: superreview+
Comment on attachment 69584 [details] [diff] [review] Propose patch. Darin, will this suit you? r=gagan
Patch checked in. Marking FIXED.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Darin: is there a set of steps you want me to run on allplats, or can you verify this as code change?
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
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?
Summary: browser hangs temporarily if switched offline while DNS thread is inside gethostbyname → DNS: Offline: browser hangs temporarily if switched offline while DNS thread is inside gethostbyname
yup.. that's what i meant.. and yes, only a linux testcase :)
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.