Closed Bug 190003 Opened 22 years ago Closed 22 years ago

cannot open links when pipelining enabled, URLs load forever, process not terminated on exit

Categories

(Core :: Networking: HTTP, defect, P2)

Product:
Core
Component:
Networking: HTTP
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.3beta

People

(Reporter: tever, Assigned: darin.moz)

References

(
URL
)

Details

(4 keywords, Whiteboard: [pipelining])

Attachments

(1 file)

v1 patch
1.33 KB, patch
dougt
: review+
bzbarsky
: superreview+
dbaron
: approval1.3b+
Details | Diff | Splinter Review 
Overview Description:  After clicking on link at www.amazon.com with pipelinging
enabled, I cannot browse anywhere else - no other links will open.

Steps to Reproduce:
1.)  In prefs, enable pipelining for direct connections
2.)  Go to http://www.amazon.com
3.)  Select the books tab
4.)  In "Search books" type in some text (such as 'dragon')
5.)  Under "See matches in", click on "Science Fiction"
6.)  Click on one of the resulting recomended books

Actual Results:  Hour glass and throbber spins.  Pressing stop or waiting for
these to stop results in pages links not working.  Clicking on any link
afterwards results in more spinning.  

Expected Results:  You should be able to open links and browse to other sites.

Build Date & Platform Bug Found:  Win NT 2003012108

Additional info:  Had to shut down in order to use browser again.  Disabling
pipeling worked fine.  Server is Apache.   Didn't work when searching for other
topics either.
Whiteboard: [pipelining]
Seeing this on 2003012008, Windows 98. It caused Mozilla to do bad things on
Windows 98. Namely, Necko seemed to die, though the rest of Mozilla was fine.
Then, when I closed Mozilla, the process would not terminate on its own,
requiring Ctrl-Alt-Del to terminate it.
Keywords: mozilla1.3, regression
I've been seeing this for a couple of days, although could not reproduce a site
/ action that caused it.  I'm glad to see that somebody's filed a bug that can
be reproduced.

Modifying Summary for better Bugzilla queries.

Raising severity to critical since this is effectively a crash (Mozilla
effecitively stops responding - you can open more tabs/windows but they never
load either, and the process must be kill manually).  Also adding crash keyword.
Severity: normal → critical
Keywords: crash
Summary: cannot open links when pipelining enabled → cannot open links when pipelining enabled, URLs load forever, process not terminated on exit
Flags: blocking1.3b?
Darin:  I am not seeing this on the baseline build I had looked at earlier last
week (pre fix for bug# 176919).  It does show up on the patched build.  So I
think this could possibly be caused by one of the patches from that bug.
ok, thanks tever!
Severity: critical → major
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.3beta
*** Bug 190398 has been marked as a duplicate of this bug. ***
I believe i saw this on Linux today. If it was the same bug, it also prevents
mailnews from doing any further network connections.
yes, this bug also occurs on linux trunk (20030123).
OS: Windows NT → All
http://www.online.no/ is a site i have problems with today 
(my ISP's customer homepage)
*** Bug 190417 has been marked as a duplicate of this bug. ***
Hardware: PC → All
another one that we probably want for 1.3
Flags: blocking1.3b? → blocking1.3b+
*** Bug 190453 has been marked as a duplicate of this bug. ***
I'm seeing this on a trunk winxp build - 2003012315.

I noticed it when loading several URLs via a bookmark group I frequent.
Keywords: topembed
disabling pipelining fixed it for me. I also see the lingering process after
shutting down.

I don't see a crash though... not sure about the crash keyword.
The fact that the browser simply stops working is what I'd define as a "crash".
   Maybe no error message is generated, but it still becomes useless.  In fact,
it's actually worse than a regular crash since you think that the target site is
simply down or something (endless loading) and it take a little while to realise
that it *has* crashed.
I just went from 1/21-9 to 1/24-04 and the problem seems to be much worse in
this build.  I had to exit Mozilla and kill the process 4 times in a five minute
period - much more often than I had to with the earlier build.

Is it possible that something checked in between 1/21 and 1/24 has made the
situation worse?  (That might provide a clue to the cause, more specific than
just pipelining.)
this is still not a crash... a crash brings with it the lack of opportunity to
save data (email, URL or other dataloss).
Keywords: crash
Putting keyword back in.  When this happens, data is lost.  If I open a series
of tabs from a reference site that I want to read and the bug occurs, I have no
easy way of re-loading those tabs once I restart the browser.  Also, form data
that might have been worked on (especially if the crash occurs just before you
try to click Back to edit something) is lost.

In fact, now that I write this, adding dataloss keyword because if it Mozilla
stops responding at the wrong time you could lose a lot of work.
Keywords: crash, dataloss
still not a crash - that's a hang, which has a different keyword - see
http://bugzilla.mozilla.org/describekeywords.cgi#hang

while I'm spamming to fix technicalities of the report: hangs are also critical
severity, and the "mozilla1.3" keyword is obsolete in favour of the blocking
flag, which this has already.  now we should shut up and let people fix the bug.
Severity: major → critical
Keywords: crash, mozilla1.3 → hang
This is still a problem in 2003012408.  I wouldn't say it was a crash per se,
but it's still a major blocker and basically renders the browser unusable with
pipelining.  Whatever, this needs to be given priorit IMHO.
Darin has said elsewhere that pipelining bugs aren't generally a high priority
because pipelining is explicitly experimental (and can always be turned off). 
Which I think is a fair stance.

Yeah, but this needs to be fixed for 1.3 beta, or at least for 1.4.
Attached patch v1 patch — — Splinter Review 
straightforward patch: the send buffer for pipelining was incorrectly
implemented as a blocking pipe.  it should have been a non-blocking pipe!

some history:
at one point during the development of the patch for bug 176919, the pipe's
behavior was such that it would not block a write call if it successfully wrote
something.  it would return a partial write.  this behavior masked this problem
during the testing of bug 176919.  late in the development cycle it was
realized that this behavior of a blocking pipe caused problems for certain
mailnews protocols and indeed it seems odd that a blocking pipe wouldn't block
until it wrote everything passed to its write method.  so the behavior was
changed, and pipelining obviously wasn't well tested afterwards :(
Comment on attachment 112535 [details] [diff] [review]
v1 patch

seeking reviews.  fairly simple patch.	i've tested it thoroughly.
Attachment #112535 - Flags: superreview?(bzbarsky)
Attachment #112535 - Flags: review?(dougt)
Attachment #112535 - Flags: superreview?(bzbarsky) → superreview+
*** Bug 190502 has been marked as a duplicate of this bug. ***
Attachment #112535 - Flags: review?(dougt) → review+
Comment on attachment 112535 [details] [diff] [review]
v1 patch

seeking drivers approval for this patch.  brain-damaged bug on my part.  simple
fix.
Attachment #112535 - Flags: approval1.3b?
*** Bug 190548 has been marked as a duplicate of this bug. ***
Attachment #112535 - Flags: approval1.3b? → approval1.3b+
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
verified - win, mac, linux - 01/30/03 trunk
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: