Closed Bug 100826 Opened 23 years ago Closed 21 years ago

Networking code seems to hang; throbbers spin without progress.

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: deven, Unassigned)

Details

Attachments

(1 file)

tcpdump log
4.34 KB, text/plain
Details 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2+) Gecko/20010731
BuildID:    2001073106

All too often, I've found my Mozilla windows to be less than responsive, and
when this happens, it's often quicker to start Netscape 4 to fetch a page than
to wait for Mozilla to finish with whatever it's busy doing.  The throbbers
spin, but all windows just seem to pause in fetching any data from the network,
even with sites which may be working fine from Netscape 4 at the same time. 
Usually, the delay is only seconds, but it's not uncommon to take minutes. 
Every once in a while, it just hangs entirely.

Today is a Thursday.  On Tuesday, I was browsing and it hung entirely.  To see
if it would eventually finish, I left several pages trying to load, with the
throbbers spinning.  Literally TWO DAYS later, they were still spinning, having
made no progress at all.  This includes a window that was launched defaulting to
my home page of www.google.com, which is generally a responsive site.  Although
Mozilla was responding to UI input, menus worked and I could even create new
browser windows, it was completely useless.

There were no dialog windows, even after days of trying to fetch a URL from the
network -- this didn't appear to be related to TCP/IP errors at all.  I doubt
the TCP connections were even being attempted, though I didn't trace anything to
find out.

This problem has been getting more and more annoying over the last few months
(and I don't remember it happening early this year), and it's getting to the
annoyance level that I'm seriously considering going back to Netscape 4 as my
primary browser, after using Mozilla as my primary browser for about 10 months
now.  This is a serious problem.

My gut instinct tells me that this might be related to DNS lookups, but I'm not
sure whether or not that's actually the case.  Currently, are DNS lookups fully
asynchronous, or are they serialized?  Could that part of the code be getting
locked out by a semaphore or anything like that?  (Maybe it's something else
entirely?)
Please try a recent build. The one you are reporting this bug with seems to be 7
weeks old, which is normally too old to be of value bug-wise.
See http://www.mozilla.org/quality/bug-writing-guidelines.html

Quote: "Next, be sure that you've reproduced your bug using a build released
within the past three days."

FYI: The spinning icon doesn't necessarily indicate network activity - the
socket itself times out after a few minutes. When a bug like the one you
describe occures, you can let mozilla spin on for a year for that matter: it
won't retry to open a socket/connection unless explicityly told so again.

I haven't seen such "spinning" bugs for quite a while now - WFM with a current
CVS build, linux.
The only way to reproduce it with a recent build is to update Mozilla daily,
since I can't reproduce it on demand, and it's erratic.  That's a nuisance when
I often leave Mozilla windows open for days at a time.  I just downloaded
today's build, but I don't know when I'll see it happen again.  Certainly, I'll
add a comment here if I see it again.  Usually it's not as blatent as this last
occurrence -- more commonly, it's slow but it eventually recovers -- long after
Netscape 4 could fetch and render the page...  (And in such situations, I often
do launch Netscape 4 to fetch the page that's dragging...)
Okay, I've just reproduced the problem with 2001092106, although not to the
extremes as the original report.  Is 6 days also too old?

I was at the following page:

     http://www.uclick.com/client/cap/gm/2001/09/10/index.html

It was taking a very long time to load this ad image at the bottom of the page
(I think; maybe this is different, if it's dynamically selected):

    
http://ads1.intelliads.com/html-bin/adselect100.asp?obnum=609600&site=85390&cbvar=6286

I wanted to look through the cartoons from other days, and selected September 11
from the drop-down and hit the "click" button to load it.  The browser started
spinning, but nothing else was happening.  Meanwhile, I launched a new browser
window and it was stuck (spinning) trying to load my homepage, www.google.com.

After a number of seconds, I launched a Netscape 4 window and went to the same
page that was first stuck in Mozilla.  It loaded fine in a couple seconds.  Then
I selected September 11 the same way and clicked on the button.  That loaded in
a couple seconds also.  I then loaded and viewed September 12, September 13,
September 14, September 18 and September 19 in sequence -- and then Mozilla
FINALLY loaded September 11, and the other windows unfroze and Google loaded.

This is exactly the same problem I described last week.  This is the bug that's
starting to make me regret making Mozilla my primary browser almost a year ago. 
What will it take to get this bug investigated?  (If someone wants to give me
any pointers as to where in the million lines of code to look, I'll look into it
myself -- where is the DNS lookup code?)
Deven: Are you using a proxy or do you have direct connection to Internet?

See the duplicate bug.



*** This bug has been marked as a duplicate of 95499 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
This bug is NOT fixed, but it does look like a duplicate of bug 95499, so I'll
try to move the discussion there if possible.  If that bug doesn't get reopened,
I'll have to reopen this one.

I've reproduced this on build 2001100321, which was the most recent nightly
build as of an hour ago.  I described in bug 95499 how I reproduced it.  I am
not using a proxy, only a direct Internet connection.
I'm reopening this bug, because bug 95499 was marked as FIXED.  Duplicate or
not, this bug isn't resolved.

Here's my relevant comments from the other bug report, duplicated here now that
I'm reopening the bug.  These were written yesterday:

[...]

I just reproduced this with the latest nightly, 2001100321.  I have a test CGI
that normally returns very consistently in about 0.25 seconds.  I went to the
test page http://www.uclick.com/client/cap/gm/2001/09/10/index.html which was
mentioned under bug 100826, and kept selecting different days (and clicking on
the "click" button) until one got stuck.  As soon as that happened, my other
window talking to the test CGI froze also.  It took 74 seconds for the test
window to unfreeze itself, and then the test CGI also unfroze.  Only at the very
END of that 74 seconds did it open the connection to fetch the test CGI -- I was
running a tcpdump and saw the SYN packets go out only at the very end.  The test
CGI was at http://escher.ties.org/cgi-bin/date for testing, but that's close to
me on the network (it's my home machine), and may not work for others to test.

I've already uploaded that test CGI under bug 40867 on 7/20/01, if anyone wants
to use it locally for testing.  It returns a date, tries to suppress caching,
and has a GET link and a POST button to retrigger the CGI.

Is there some sort of maximum connection limit causing this?  I am NOT using a
proxy, but it seems to refuse to open new connections when (enough?) old ones
are hung due to network problems at other sites...
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
I sometimes see this when I go to Slashdot. The browser resolves, and then
transfers data till the progress meter is halfway. Then all network activity
dies and I never go to the page. This means that I often have to view slashdot
in NS4.

It is not 100% reproducable, but it appears to me that mozilla is ignoring some
packet and is just waiting and waiting for it to come.

I've never had other windows of mozilla stop responding networkly though, so
this might be a seperate bug.

Does anyone have a TCP log of their connections that they could post to this
bug? It would make confirming that much easier.
I see this as well - Linux RH 7.2, on a wide variety of builds over the past few
months. It occasionally happens in Mail/News also. It's basically as if Necko
just ignores everything the browser tells it and anything coming in over the
network. Type in a new URL and press enter and nothing happens at all.

I normally restart Mozilla to fix it - but it is annoying.

Gerv
Status: UNCONFIRMED → NEW
Ever confirmed: true
found similar problem at www.ual.com.  Click on "advanced search" link upper
left of page, then on next page click on "log in as guest" link.  You get a
"Please wait while we retrieve the information" message and a bouncing ball that
never stops.  sounds like same bug.  Using Mozilla 0.9.6, build 2001112009, same
problem with Netscape 6.2, works with IE 6
Bob McConnell
the www.ual.com bug is a problem on the server side w/ not sniffing mozilla
properly.  cc'ing jst, who own(s/ed) that bug.
Original reporter, do you see this bug in recent nightlies?
If not -> WFM Linux 2002010621

I've noticed this bug since at least 0.9.4 (when I started seriously using
mozilla). A web site that frequently causes this problem for me is espn.go.com.
Usually I will load up that page, click on a link to read a story, then try to
hit the back button and mozilla stops downloading any pages for a while. I'm
currently running 0.9.7 (Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7)
Gecko/20011227) on FreeBSD 4.4.
Reporter: is this stil a problem
Keywords: qawanted
chris: i played around with stuff on espn's website using the 2002011108 linux
build and didn't encounter any problems.  can you describe how you connect to
the internet?  for example, are you connecting via a web proxy?  and if so, do
you know what kind of proxy it is?  thx!
This continues to be a problem, even with current builds. I use Mozilla at work
also, but I never have this problem there. The only obvious difference between
the two machines is that the problem one is running Win 98 and my work machine
is Win 95.
Mozilla/5.0 (X11; U; Linux alpha; en-US; rv:0.9.8) Gecko/20020205
I think I am seeing this bug, although the it does seem a bit different (except
for Gerv, comment #8).  I am completely unable to load any URL.  One time, it
transferred all the data and then waiting 30 seconds, and then displayed the
page.  Other than that one time, the throbber just keeps going forever.
Attached file tcpdump log — 
tcpdump log connecting to http://www.mozilla.org/start.

I used sniffit to verify that all of the html and css pages were successfully
transferred.  Also, Netscape, lynx and a new instance of Mozilla are successful
in loading the URL.
I should add that none of the page is displayed.  Shouldn't Mozilla display the
page as it receives it?

Also, general browser performance while the bug is active is very slow, although
it only uses negligible CPU.
Reporter: Can you try to reproduce this bug with the latest build?
Target Milestone: --- → Future
I would be very interested in learning if this is occurring because a DNS
lookuup fails, and blocks further DNS requests in mozilla.

Or, it could be some general blockage of everything.

The way to test is to try to connect to an IP address after you encounter the
initial hangups.
Currently, I cannot verify whether or not this problem remains.  My networking
configuration changed in December, and I am now behind a firewall, and all my
web browsing is through a SOCKS proxy that tunnels through SSH to my home
machine where the SOCKS server is running.  This works, but it's slower than a
direct connection, and I get many delays and hangs due to the proxy that make it
hard to watch for this problem.

However, there's a possibility that I may get an opportunity to move my machine
outside the firewall.  If so, maybe I'll be able to determine whether or not
this bug has been quashed.  For now, it probably needs to remain undetermined...
moving neeti's futured bugs for triaging.
Assignee: neeti → new-network-bugs
I'm assuming this bug is fixed.  I haven't seen this behavior in well over a year.
Status: NEW → RESOLVED
Closed: 23 years ago → 21 years ago
Resolution: --- → FIXED
thanks for the response !
(but no patch = not fixed)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
-> wfm
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → WORKSFORME
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: