Corrupt cache / HTTP networking - Wrong images, incomplete pages, octet-stream download dialog

RESOLVED FIXED in mozilla1.4alpha

Status

()

Core
Networking: Cache
P2
major
RESOLVED FIXED
15 years ago
15 years ago

People

(Reporter: WD, Assigned: Darin Fisher)

Tracking

(Blocks: 1 bug, {topembed+})

Trunk
mozilla1.4alpha
topembed+
Points:
---
Bug Flags:
blocking1.3 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [pipelining], URL)

Attachments

(4 attachments)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030303
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030303

When going a search on Google, I often get rather than the complete Google
search page, just a single image from the page that is supposed to come up.

Reproducible: Sometimes

Steps to Reproduce:
1.Go to
http://http://groups.google.com/groups?q=PCI+Delay+Transaction&hl=en&lr=&ie=UTF-8&safe=off&selm=ynzw5.2080%24At6.84196%40nnrp1.sbc.net&rnum=2
2.Keep doing a Shift-Reload
3.

Actual Results:  
Sometimes just a single image, sometimes an octet-stream download dialog, and
sometimes a page, but with images within the page switched.

Expected Results:  
Page loads up fine

Disabling HTTP Pipelining has no effect on the problem.
If I go to the Page Info screen of any of the resulting pages, it says the
source is Disk Cache, even though I'm using Shift-Reload
(Reporter)

Comment 1

15 years ago
Created attachment 116099 [details]
Page Load #1
(Reporter)

Comment 2

15 years ago
Created attachment 116100 [details]
Page Re-Load
(Reporter)

Comment 3

15 years ago
Created attachment 116102 [details]
Page Re-Load #3 ( Since Reload #2 looks OK)

Comment 4

15 years ago
Using Build 2003030208 and Windows XP, I saw similar problems with
www.mozdev.org. The problems were gone after I disabled HTTP Pipelining.

Now I reenabled HTTP Pipelining again, cleared the cache before I did so and
can´t reproduce this bug anymore.

I´m going to remove the "with google.com" part from the bug summary because this
happens with www.mozdev.org and probably other sites too.
Summary: Corrupt cache / HTTP networking with google.com - Wrong images, incomplete pages, octet-stream download dialog → Corrupt cache / HTTP networking - Wrong images, incomplete pages, octet-stream download dialog

Comment 5

15 years ago
I see a similar behaviour on 1.3b / Linux / ia32.  My home page almost always
looks weird in different ways, all related to image placement:

  http://www.student.nada.kth.se/~d92-jwa/

Each time I reload it (by holding down SHIFT and clicking the reload button in
the toolbar) I get different behaviour.

Updated

15 years ago
Flags: blocking1.3?
OS: Windows 2000 → All

Comment 6

15 years ago
possible dupe of bug 194934?

Comment 7

15 years ago
cc'ing darin because of possible http pipelining interaction.

Updated

15 years ago
Flags: blocking1.3? → blocking1.3-
(Reporter)

Comment 8

15 years ago
I've disabled HTTP Pipelining and the problem hasn't happened for days.
As soon as I've re-enabled it, it's back again.    Looks like it's definately
pipeline-related.

If this is bug 194934 , then the summary of that bug should definately be updated.
(Assignee)

Comment 9

15 years ago
-> me (been accumulating related bugs... will take care of duping)
Assignee: gordon → darin
Priority: -- → P2
Whiteboard: [pipelining]
Target Milestone: --- → mozilla1.4alpha
could be dup of bug 162889
(Assignee)

Comment 11

15 years ago
*** Bug 197595 has been marked as a duplicate of this bug. ***

Comment 12

15 years ago
I just like to point out pipelining works fine in 1.2.1.   Ever since I upgrade
to version 1.3b&1.3, this problem pops up a lot.  I tested my other comp system
and confirm this.
(Assignee)

Comment 13

15 years ago
yeah :(  this is something i will do my best to fix for 1.4 alpha!
Status: NEW → ASSIGNED
Flags: blocking1.4a?
(Assignee)

Comment 14

15 years ago
Created attachment 117646 [details] [diff] [review]
v1 patch

fairly simple patch.  we weren't propogating errors to the nsHttpConnection
instance properly.  this patch overlaps some with my patch for bug 159015.
(Assignee)

Updated

15 years ago
Attachment #117646 - Flags: review?(dougt)
(Assignee)

Comment 15

15 years ago
*** Bug 194934 has been marked as a duplicate of this bug. ***

Comment 16

15 years ago
Setting Hardware=All per comment 15.
Hardware: PC → All

Updated

15 years ago
Attachment #117646 - Flags: review?(dougt) → review+
(Assignee)

Updated

15 years ago
Attachment #117646 - Flags: superreview?(bzbarsky)
(Assignee)

Comment 17

15 years ago
*** Bug 196099 has been marked as a duplicate of this bug. ***
Comment on attachment 117646 [details] [diff] [review]
v1 patch

So is the only point of mClosed in nsHttpTransaction that it prevents calling
into Close() multiple times?  If so, could you please comment that in the class
def?  mClosed and mTransactionDone are a little confusing as things stand....

Also, do you want to log the error returns on closed status in nsHttpPipeline? 
(this is not a real review comment, obviously, just a question)
Attachment #117646 - Flags: superreview?(bzbarsky) → superreview+
(Assignee)

Comment 19

15 years ago
bz:

yeah, mClosed is meant to prevent multiple calls to Close as well as calls to
Read/Write after Close has been called.  mTransactionDone has slightly different
meaning... i will document this better.  basically, there are these three flags:

  mClosed            -  transaction has been closed
  mTransactionDone   -  transaction ran to completion or was interrupted
  mResponseComplete  -  transaction ran to completion

it could happen that mTransactionDone is set before the transaction is closed,
and closing a transaction (the connection does this) could indicate EOF _or_ an
interrupted stream (depending on how the transaction is determining EOF).

as for adding more logging to nsHttpPipeline.. i don't think it would really
help any.  probably the existing logging |if (mClosed)| is not necessary either.

thanks for the review!

Comment 20

15 years ago
datapoint: I've been seeing this for quite awhile w/ winxp, trunk, mozilla
builds w/ pipelining on when doing "image" searches (use the "image" tab at
google) at google. clicking on one of the resulting images shows a different images.
Keywords: topembed+
(Reporter)

Comment 21

15 years ago
*** Bug 198933 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 22

15 years ago
jud: yup, images.google.com has been my main testcase.  for some reason, this
problem is especially easy to repro there.
(Assignee)

Comment 23

15 years ago
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 24

15 years ago
*** Bug 199114 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Flags: blocking1.4a?

Comment 25

15 years ago
Note that this may not be entirely fixed. I downloaded FizzillaMach/2003032609,
re-enabled HTTP Pipelining, and accessed
<http://www.orangemicro.com/fw800pci.html>. I saw some wrong images, even after
force-reloading.
> mClosed is meant to prevent multiple calls to Close as well as calls to
> Read/Write after Close has been called.  

Then shouldn't nsHttpTransaction check the mClosed state in 
ReadSegments/WriteSegments?
(Assignee)

Comment 27

15 years ago
bz: nsHttpTransaction checks mTransactionDone, which in that context should be
equivalent to checking mClosed.  NOTE: the nsHttpTransaction actually needs to
fail on WriteSegments (w/ NS_BASE_STREAM_CLOSED) before Closed() is called
because that is how the connection learns that the transaction doesn't want any
more data.

Comment 28

15 years ago
Something is definitely still wrong. Using FizzillaMach/2003032808 with
pipelining enabled, access the URL in my comment 25. Repeatedly force-reload the
URL and eventually you'll see either a wrong image load or the load will simply
hang and never complete.

Reopen this or new bug?

Comment 29

15 years ago
greg: i see the same problem on that site.  however, i think in that case it
might be a server problem.  many servers claim to support pipelining but do not.
 this may very well be one of those servers.  a new bug would be best.  thx!

Comment 30

15 years ago
*** Bug 193228 has been marked as a duplicate of this bug. ***

Comment 31

15 years ago
Filed as bug 199675 per comment 29.
> bz: nsHttpTransaction checks mTransactionDone, which in that context should be
> equivalent to checking mClosed.

Document this?  ;)

Comment 33

15 years ago
*** Bug 199389 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 34

15 years ago
*** Bug 192546 has been marked as a duplicate of this bug. ***

Comment 35

15 years ago
*** Bug 198156 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 36

15 years ago
*** Bug 140530 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 37

15 years ago
*** Bug 200698 has been marked as a duplicate of this bug. ***

Comment 38

15 years ago
Running: Moz 1.4a (NT4)

Sometimes, visiting a new URL results in a new page that simply displays a zero:

0

This is inconsistent with the page source; the page will render correctly when I
reload. This appears to be the leading zero that I mentioned in bug 200698,
minus the http header bleed.  Pipelining is off.

Comment 39

15 years ago
Anthon, please file that as a new bug.

Comment 40

15 years ago
Greg - Anthon already filed it as a bug. it was marked as a duplicate of this
bug, so he commented here. that bug has now been reopened based on the comment.

(Anthon - future comments should, of course, go into bug 200698)

Updated

15 years ago
Blocks: 123929
(Reporter)

Comment 41

15 years ago
*** Bug 201052 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 42

15 years ago
*** Bug 199546 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 43

15 years ago
*** Bug 194642 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 44

15 years ago
*** Bug 133734 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 45

15 years ago
*** Bug 202210 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 46

15 years ago
landed patch on 1.3 branch per request from asa.

Comment 47

15 years ago
The patch to the 1.3 branch seems to fix Mozilla proper.  However, galeon-1.3.3
linked against the same Mozilla 1.3 libraries still exhibits the problem.  While
it shouldn't be required, I even rebuilt Galeon after applying the patch and
rebuilding Mozilla.  Any idea why I might still see this problem?  Note, Galeon
linked against 1.4a does not exhibit this problem.
(Assignee)

Comment 48

15 years ago
Joe: nope, i have no idea... sorry! :(

Comment 49

15 years ago
*** Bug 204524 has been marked as a duplicate of this bug. ***

Comment 50

15 years ago
*** Bug 202091 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.