DNS timeout can cause browser stall




19 years ago
18 years ago


(Reporter: david+bugs, Assigned: warrensomebody)



Firefox Tracking Flags

(Not tracked)




(1 attachment)



19 years ago
From Bug Helper:
User-Agent: Mozilla/5.0
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.

Comment 1

19 years ago
Created attachment 5199 [details]
Trace dump when browser is stalled at high CPU use

Comment 2

19 years ago
dns timeouts?
Assignee: gagan → gordon

Comment 3

19 years ago
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

Comment 4

19 years ago
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+.
Keywords: beta1
Priority: P3 → P1
Target Milestone: M14

Comment 6

19 years ago
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
Dns over to warren.
Assignee: dp → warren

Comment 8

19 years ago
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.

Comment 9

19 years ago
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.


Comment 10

19 years ago
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.
Whiteboard: [PDT+]

Comment 11

19 years ago
Actually I'm wrong. We did eventually time out after several minutes. A dialog 
came up and everything.

Comment 12

19 years ago

*** This bug has been marked as a duplicate of 10733 ***
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE

Comment 13

19 years ago
verified dupe of 10733

Comment 14

18 years ago
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.