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

Status: RESOLVED FIXED

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

Description

[WD]

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

Comment 1

[WD]

Attachment: Page Load #1

Comment 2

[WD]

Attachment: Page Re-Load

Comment 3

[WD]

Attachment: Page Re-Load #3 ( Since Reload #2 looks OK)

Comment 4

[Stefan Borggraefe]

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.

Comment 5

[Johan Walles]

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.

Comment 6

[Chris Casciano]

possible dupe of bug 194934?

Comment 7

[gordon]

cc'ing darin because of possible http pipelining interaction.

Comment 8

[WD]

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.

Comment 9

[Darin Fisher]

-> me (been accumulating related bugs... will take care of duping)

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

could be dup of bug 162889

Comment 11

[Darin Fisher]

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

Comment 12

[legendofavatar]

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.

Comment 13

[Darin Fisher]

yeah :(  this is something i will do my best to fix for 1.4 alpha!

Comment 14

[Darin Fisher]

Attachment: 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.

Comment 15

[Darin Fisher]

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

Comment 16

[Greg K.]

Setting Hardware=All per comment 15.

Comment 17

[Darin Fisher]

*** Bug 196099 has been marked as a duplicate of this bug. ***

Comment 18

[Boris Zbarsky [:bzbarsky]]

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)

Comment 19

[Darin Fisher]

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

[Judson Valeski]

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.

Comment 21

[WD]

*** Bug 198933 has been marked as a duplicate of this bug. ***

Comment 22

[Darin Fisher]

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

Comment 23

[Darin Fisher]

fixed-on-trunk

Comment 24

[R.K.Aa.]

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

Comment 25

[Greg K.]

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.

Comment 26

[Boris Zbarsky [:bzbarsky]]

> 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?

Comment 27

[Darin Fisher]

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

[Greg K.]

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

[Cathleen]

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

[Avi Drissman]

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

Comment 31

[Greg K.]

Filed as bug 199675 per comment 29.

Comment 32

[Boris Zbarsky [:bzbarsky]]

> bz: nsHttpTransaction checks mTransactionDone, which in that context should be
> equivalent to checking mClosed.

Document this?  ;)

Comment 33

[Greg K.]

*** Bug 199389 has been marked as a duplicate of this bug. ***

Comment 34

[Darin Fisher]

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

Comment 35

[Greg K.]

*** Bug 198156 has been marked as a duplicate of this bug. ***

Comment 36

[Darin Fisher]

*** Bug 140530 has been marked as a duplicate of this bug. ***

Comment 37

[Darin Fisher]

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

Comment 38

[Anthon Pang]

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

[Greg K.]

Anthon, please file that as a new bug.

Comment 40

[Michael Lefevre]

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)

Comment 41

[WD]

*** Bug 201052 has been marked as a duplicate of this bug. ***

Comment 42

[Darin Fisher]

*** Bug 199546 has been marked as a duplicate of this bug. ***

Comment 43

[Darin Fisher]

*** Bug 194642 has been marked as a duplicate of this bug. ***

Comment 44

[Darin Fisher]

*** Bug 133734 has been marked as a duplicate of this bug. ***

Comment 45

[Darin Fisher]

*** Bug 202210 has been marked as a duplicate of this bug. ***

Comment 46

[Darin Fisher]

landed patch on 1.3 branch per request from asa.

Comment 47

[Joe Marcus Clarke]

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.

Comment 48

[Darin Fisher]

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

Comment 49

[Stefan Borggraefe]

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

Comment 50

[noririty]

*** Bug 202091 has been marked as a duplicate of this bug. ***