Closed
Bug 174733
Opened 22 years ago
Closed 21 years ago
DNS: hangs on lookups and at various stages
Categories
(Core :: Networking, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: hamish, Assigned: gordon)
References
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529
At various stages of opening connections or resolving addresses the whole of
Mozilla (i.e. all open windows of current instance, including
browser/news/mail/composer etc) will lock and pause for anywhere from 60secs to
infinity, with no window updates. Rolling animation of Mozilla icon on top RH
corner pauses as well in mid animation.
Usually Mozilla then just continues, sometimes it just hangs forever until kill
-9'ed
Reproducible: Always
Steps to Reproduce:
1. Just general browsing...
2.
3.
Actual Results:
Paused for 30-60 seconds.
Expected Results:
Continued on...
Reporter, try a newer mozilla build.
I don't see any of the issues mentioned on Linux with mozilla cvs 20021015
Reporter | ||
Comment 2•22 years ago
|
||
Release 1.0.1 has same problem. Opera on same machine works fine.
Comment 3•22 years ago
|
||
hmmm, I am not able to reproduce this either and I'm not seeing any similar
reports. (tested moz1.0.1 on linux)
reporter: Are you seeing this on all urls you type in or just a few? After
establishing connection does the page render smoothly? Are you behind a
firewall that could somehow be interfereing with the connection process?
I've encountered this bug also, recently. First seen on Mozilla 1.1 release, so
I upgraded to 1.2 but have the same problem. I have been able to reproduce on 2
different computers with the following information:
Linux OS/Redhat 8.0
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016
Mozilla icon on the TOP window does freeze (but not in lower windows)
After encountering the initial DNS hangup, other DNS lookups sometimes fail too
and require a kill -9 of mozilla. I tried to do an nslookup at that moment while
Mozilla is hung-up, and am able to resolve the locations fine. They return a
large number of IPs usually. Mozilla hangs with "Resolving host abc.def.ghi.jkl"
and when opening a new window typically all other hyperlinks fail as well.
To reproduce (caution 18+ URL, but it's the only one that consistently fails
which causes the condition)
1) go to http://www.voyeurweb.com/main/Main.html
2) click on the fifth link down on the lefthand side "Voy Photos"
3) the URL that will not resolve is http://voy.voyeurweb.com/main/Pictures.html
Summary: Mozilla hangs/pauses on dns lookups and at various stages of making tcp connections → DNS: hangs/pauses on lookups and at various stages of making tcp connections
+clean-report
It seems that we have a couple lingering, hard-to-reproduce DNS bugs w/ hanging
and lag.
I'm escalating them w/ "clean-report" (even though the descriptions are not
idea), so we can group the data and try to figure out what is going on.
Keywords: clean-report
per bug 181135: all bugs owned by previous default owner that were not futured
are being reassigned to default owner.
Assignee: new-network-bugs → dougt
I have experienced this in **Win2K** builds for as long as I remember (> 1yr).
Present in 1.3 final and early 1.4 ones.
Also, here is (one of many, this one in my bookmarks) that it occurs at:
http://www.freep.com/comics/index.htm
On a 1.7GHz Dell on a high speed campus connection the hangs normally last for
about 5-10s.
Comment 8•22 years ago
|
||
I've seen the same thing. Not as obvious when using a direct connection, but
when I've got Mozilla going through the Squid proxy here at work it hangs before
even connecting to the proxy. Here's a synopsis of a network capture of me
trying to connect to www.mypce.com (the first column is the time)
0.0s -- DNS lookup www.mypce.com
0.2s -- DNS answer "Server Failure"
0.2s -- DNS lookup www.mypce.com.ln9.net
0.2s -- DNS answer NXDOMAIN
2.4s -- GET http://www.mypce.com/ HTTP/1.1 (from already established proxy
connection)
My proxy autoconfiguration script contains:
-- snip --
if (isInNet(host, "192.168.100.0", "255.255.255.0")) {
return "DIRECT";
}
-- snip --
so Mozilla definately needs the IP of the host. I don't know what it is doing
for those 2.2s but every window of Mozilla is hung. It really becomes a problem
if you hit a forum which contains images in people's sigs that are from borked
urls, where Mozilla will pause for 5-15 seconds or more.
My system is Mozilla 1.3 on Win2k.
changed summary.
Lets focus on just hanging conditions that required being killed.
emmet: your problem sounds more like a long pause, so we might need to find you
a new bug. There is an open bug on fixing DNS serialization for UNIX (which
implies that it is NOT serialized for Windows, but I have seen one or two
complaints for windows).
Bryan:
you should move your problem to a new bug. IsInNet() is very slow because if you
use to to select your direct network, you basically have to DNS error before you
call the proxy. We don't have a negative DNS cache, so this happens every time
(bug 208312).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: DNS: hangs/pauses on lookups and at various stages of making tcp connections → DNS: hangs on lookups and at various stages of making tcp connections
Comment 11•22 years ago
|
||
I definitely see this happening on Mozilla 1.4RC, on Windows 2000.
I have been seeing this happening more often in recent builds, which is
worrisome. Older builds do not have this problem as often!
The symptoms I observe is this:
When many pages are being loaded at once, and one of those pages blocks for DNS
(perhaps the DNS server for that page, or something else referenced from that
page, is being slow), ALL pages will then STALL while waiting for that DNS
problem to be resolved! It's as if DNS is being serialized internally somehow.
From this point, it will either clear up on its own after a long wait (around 60
seconds), with all the pages rapidly loading from that point - or unfortunately
stall forever. When the pages stall forever, the only course of action is to
hit Stop, which is frustrating because it causes the URL's of all stalled pages
to be lost, making Reload impossible (another unrelated Mozilla bug).
During the time this stall is happening, I can do ping, traceroute, and use
MSIE. All other tools work fine!
I can reproduce this almost at will, by looking at a page with many links to
different servers (like Slashdot), then rapidly middle-clicking many different
links. This opens many new tabs in the background (I have all boxes checked
under Tabbed Browsing). More often than not, a few tabs will load instantly,
then a DNS problem will happen, causing all other tabs that have not yet loaded
to become stalled! This doesn't happen all of the time, but happens a
significant percentage of the time.
Assignee | ||
Comment 12•22 years ago
|
||
The mozilla nsDNSService uses WSAAsyncGetHostByName() on windows, and makes sure
to release locks while waiting for outstanding calls to complete. The mozilla
code can theoretically handle 128 simultaneous outstanding gethostbyname calls
before it returns a failure. There could be limitations in the OS resolver
however that cause serialization of DNS requests.
DNS requests on *nix platforms are currently serialized (bug 70213).
Comment 13•21 years ago
|
||
I see this problem in 1.5 - more so than 1.4 or previous versions. It seems to
be more easily reproduced when I type in bad URLs, like 'www.asdfakjsdjf.com',
but not necessarily all the time. I always use tabbed browsing, so I always have
other tabs open, but I've had it happen to me while loading only a single tab.
It happened once on my workstation at work yesterday ( RH9 w/all updates ) and
immediately after I upgraded my home computer ( also RH9 with all updates ). I
used the rpm build for Redhat 9 from the download page.
When I search for any web addresses using dig or just pinging them, they all
work. But Mozilla just sits there. I then eventually have to 'killall mozilla-bin'.
Comment 14•21 years ago
|
||
david: the mozilla host resolution system was rewritten recently for the
upcoming mozilla 1.6 alpha release. i suggest you give a nightly build of
mozilla a try. it should eliminate or at least greatly reduce the problem you
describe. please let us know if it does not! :)
Comment 15•21 years ago
|
||
I have had this problem recently as well, starting with 1.4 and
now with 1.5 (RedHat 9, updated, Mozilla 1.5 from RPM).
I was using our local name server, but tried a caching nameserver
on the local box. The problem was not fixed. host <name>
resolves, but mozilla just hangs and will not load any more pages,
forcing an exit and a killall -9 mozilla-bin.
Comment 16•21 years ago
|
||
wade: please try mozilla 1.6 alpha. see comment #14 for more details.
Comment 17•21 years ago
|
||
Duplicate of bug 208287
PAC: IsInNet can cause lengthy UI hangs on DNS lookup failure
Comment 18•21 years ago
|
||
I can confirm that this bug also happens on Firebird 0.7 (which is based on
Mozilla 1.5).
BTW, bug 208287 addresses PAC issues, and so it isn't an exact duplicate of this
bug. Both bugs stem from the same symptom, though.
I would be very happy if this DNS bug is fixed!
It is maddening when attempting to open multiple websites at once. If one
website can't be looked up in DNS, then all other sites will also fail to load
and eventually time out, since every network thread in the browser comes to a
screeching halt while DNS is trying resolve. This is especially frustrating
when combined with the issue in Firebird in which sites that fail to be
contacted do not stay in the address bar, causing their URL to be completely
forgotten and "Reload" to be useless.
To me, this is the single most frustrating thing about Mozilla. I'm sure that
it drives other users away as well. I feel embarassed to have to open up MSIE
and watch it resolve pages instantly and load them immediately, while over in
the other window Mozilla is still chugging away because its DNS thread is
completely hung up!
Comment 19•21 years ago
|
||
RESOLVED/FIXED:
1.6f is coming soon, so I'm cleaning up open bugs likely fixed by the re-write.
You need to log in
before you can comment on or make changes to this bug.
Description
•