27505 - DNS timeout can cause browser stall

Status: VERIFIED DUPLICATE of bug 10733

(Core :: Networking, defect, P1)

Description

[David A. Madore]

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.

Comment 1

[David A. Madore]

Attachment: Trace dump when browser is stalled at high CPU use

Comment 2

[Gagan]

dns timeouts?

Comment 3

[rpotts (gone)]

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

Comment 4

[David A. Madore]

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).

Comment 5

[Suresh Duddi (gone)]

Another dns hangup. If this is true, this should be PDT+.

Comment 6

[leger]

Putting on PDT+ radar for beta1.

Comment 7

[Suresh Duddi (gone)]

Dns over to warren.

Comment 8

[Warren Harris]

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

[David A. Madore]

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

[Warren Harris]

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.

Comment 11

[Warren Harris]

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

Comment 12

[Warren Harris]

*** This bug has been marked as a duplicate of 10733 ***

Comment 13

[Tom Everingham]

verified dupe of 10733

Comment 14

[[e-mail]]

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.