4.77 KB, text/plain
From Bug Helper: User-Agent: Mozilla/5.0 [LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=C] (Linu BuildID: 2000012520 When it takes extremely long to resolve a host name, the browser sometimes stalls (window is redrawn but no functions work) at high CPU usage (idle loop?). Reproducible: Sometimes Steps to Reproduce: 1.Take linux box with caching nameserver but no or slow network. 2.Enter URL with inexistant host component. Actual Results: Browser stalls. Window is still refreshed (expose events are being handled) but menus, stop button, and scroll bars no longer work (on all windows). One mozilla-bin thread runs at 95% CPU usage. Expected Results: Error message (``Could not resolve host'') in popup window. This sometimes happens, but not always. Bug is not completely reproducible, but fairly enough. nscd daemon was not running. Will be adding gdb backtrace to this bug report soon.
Assignee: gagan → gordon
I believe that this is a dup of the bug that Async DNS is *not* implemented on unix yet :-) Currently, on unix, DNS lookups are done synchronously on the socket transport thread. So, if one takes a while *all* socket activity is stopped! -- rick
Assignee: gordon → dp
I don't understand much (i.e. nothing at all) about Mozilla internals, but I don't think this is merely the fact that DNS lookups are not done asynchronously. The latter (a lack of a feature but not a bug) merely means that you can't use the browser while the host name is being resolved. This bug says that after the DNS has timed out and failed, the browser becomes unusable (in lieu of displaying an error message).
Another dns hangup. If this is true, this should be PDT+.
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: M14
Putting on PDT+ radar for beta1.
Dns over to warren.
Assignee: dp → warren
Status: ASSIGNED → NEW
I guess I totally misunderstood this bug when I heard it described. I assumed that while we were in the process of doing a dns resolution on unix, no data would come in for any of the network requests (because the socket transport would be blocked). But that dns resolution would eventually time out and everything would return to normal. But it sounds like the browser is hosed perminently after this point. Can someone confirm? If we do hose the browser, then this should be PDT+. If we don't -- we just impede performance, then the PDT designation should be reconsidered.
I confirm that the browser is stalled (I assume that's what ``hosed'' means) permanently (or at least as long as my patience lasts, which is much longer than a DNS timeout). As I said, this bug is not easy to reproduce, though (I'll try to provide extra info if it is needed). It is possible that this has nothing to do with the DNS itself, but only with the error message window that should appear after the timeout.
Ok, I tried this by pulling my network cable. What I found is that the browser is functional and able to load local pages, but pages off the net never terminate. Not timing out is somewhat of an issue, but I don't think this is a beta stopper. And fixing it is not possible in a short time frame. Erasing PDT+ annotation for re-evaluation.
Actually I'm wrong. We did eventually time out after several minutes. A dialog came up and everything.
*** This bug has been marked as a duplicate of 10733 ***
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
verified dupe of 10733
Status: RESOLVED → VERIFIED
I think there are two kinds of timeouts: 1- Connection to DNS server (not really a connection b/c it's udp...) 2- Completion of all data. This is very rare and hard to reproduce. I will do some research to see if #2 exists, and if so, how to test it.
You need to log in before you can comment on or make changes to this bug.