Closed Bug 91710 Opened 23 years ago Closed 23 years ago

opening page several times quickly shows completely blank page

Categories

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

Product:
Core
Component:
Networking: Cache
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: caustin, Assigned: darin.moz)

References

(
URL
)

Details

(Keywords: topembed, Whiteboard: verified-on-trunk)

Attachments

(6 files)

Http LOG when loading www.dict.org the first time (from the net)
53.26 KB, text/plain
Details
Http LOG loading www.dict.org a subsequent time (from the cache)
21.34 KB, text/plain
Details
Patch to avoid aborting a connection if cache entry initialization fails...
753 bytes, patch
Details | Diff | Splinter Review
http log (with rpotts's fix)
19.09 KB, text/plain
Details
v1.0 seems to fix the problem
634 bytes, patch
Details | Diff | Splinter Review
v1.1 revised patch
785 bytes, patch
Details | Diff | Splinter Review 
Reproducible:  Sometimes

1) Add http://dict.org/ to your personal toolbar folder
2) Click on the button on the personal toolbar several times rapidly.  Repeat
until you get a completely blank, white page.  You have to get the timing just
perfect.

I can reproduce this very easily in my opt trunk build.  I'll try again Monday
with commercial trunk and branch builds.

Actual results:  Blank page shows up.  View Source shows <html><body></body></html>

Expected results:  Real page appears.  View Source shows contents of that page.
Okay, I just reproduced this in today's commercial branch build.  It was harder
to do though.  :)

this is probably the same as a bug that gordon, dougt, and I saw when trying to
reproduce bug 82720.
For the morbidly curious... I've attached the Http LOGs when www.dict.org is loaded.

It appears that the only "strange" thing is that the server provides *no*
caching information with the response for the document URL.    As you can see,
the response doesn't even include a "Last-Modified" header :-(

This means that the cache as no information to use when calculating
lifetime/expires times...  So, it ends up expiring immediately... Which means
that it is *always* fetched from the network...

Ok...  I've finally been able to reproduce this in the debugger and I think that
i see what's happening...  We are hitting the following ASSERT in
nsHttpChannel::InitCacheEntry(...) which is causing ProcessNormal(..) to fail !


0[355528]: nsHttpChannel::ProcessNormal [this=3963148]
0[355528]: ###!!! ASSERTION: NS_ENSURE_TRUE(mCacheAccess &
nsICache::ACCESS_WRITE) failed: 'mCacheAccess & nsICache::ACCESS_WRITE', file
R:\0.9.2\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 947
0[355528]: ###!!! Break: at file
R:\0.9.2\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 947
0[355528]: nsHttpTransaction::Cancel [this=3ad9380 status=8000ffff]
0[355528]: ignoring cancel since transaction is already done [this=3ad9380]
0[355528]: nsHttpChannel::OnStopRequest [this=3963148 request=3ad9380
status=8000ffff]
0[355528]: nsHttpChannel::CloseCacheEntry [this=3963148 status=8000ffff]
0[355528]: dooming cache entry!!


For some reason, the cache entry is marked READ_ONLY...  This causes
ProcessNormal(...) to fail without calling out to the consumer... and ultimately
cancelling the channel...

It seems as if we should be able to continue the transfer in this situation...
but just not cache it...

I heard the word 'cache'! ccing gordon.
Component: Networking → Networking: Cache
I've attached a small patch (for the branch), which seems to fix the problem...
 Basically, if calling InitCacheEntry() fails, rather than aborting the
connection, i just close the cache entry...

I think that this patch is correct - since cache failure should not cause the
connection to abort...

 However, I think that we still need to understand why/how a cache entry which
was opened read-write was returned from the cache as read-only !!

-- rick
After a bit more digging, it looks as if the patch to bug #90288 could create
the situation where a read-write cache entry was requested, but a read-only
entry is returned by the cache...

However, it looks as if bug #90288 was *just* backed out of the branch :-)

rpotts - this happens without that patch. gordon, dougt, and I were seeing this
situation by pressing reload lots of times on some of the pages in bug 82720, on
the trunk (without gagan's patch)
hmmm...  well, as i said, i think that "the patch is good" - do you still see
the empty page loads with this patch applied?

i just think that we need to understand whether the situations where we end up
with read-only cache entries are really symptoms of *other bugs* :-)
Not necessarily.  There is a difference between the access requested and the
access granted.  It is perfectly valid to request read/write access (which
reallly means - "I'm willing to accept read and/or write access"), with the
result that only read, only write, or both read and write access is granted.

Request WRITE access = I have new data to store - I don't care what's there now
Request READ access = Give me what you've got, but I can't get new data
Request READ/WRITE access = Give me what you got, but I'll get new data if necessary
well, if that is the case, the i think that this patch is definately important.
 because it allows the http ransaction to continue (uncached) if the cache
returns a read-only entry when a read-write entry is requested.


can anyone verify that this patch fixes the problem (or not).

If it does, should this be pushed as PDT+, since it is a splinter of another
PDT+ bug?

-- rick

Okay, sorry it took so long for me to test this.  I'm running with your patch
and I could still easily reproduce this puppy.

was it with the same pages? or different pages?

with this patch, i hit lots of pages that would have been displayed as blank 
(because of the read-only cache entry)...  For example, with this patch 
http://dict.org/ works...

i bet that there is yet another problem - after the one exhibited by 
http://www.dict.org/ ;-)

if you can give me some URLs, i'll start trying to track the "next" problem down
It was dict.org, with the page source: <html><body></body></html>
even after you applied the patch?  i spent a long time loading that page over 
and over again after my patch... and each time i hit the assert and the patch 
workaround which allowed the page to render...

i'll look into it more tomorrow...

Given the steps required to repro this, I'm inclined against plussing this.  If
this were happening a lot all over the place, I think we'd have heard about it
by now.  What do you think?
Do we know if the patch helps anything yet?
hey steve,

when surfing the web i occationally hit the situation where this patch will
prevent a blank page from coming up...  the www.dict.org test case was just the
"most reliable" way of reproducing the bug - because it is inherently random...

without this patch, the work around is to hit RELOAD and the page should display
correctly...

i'm still trying to get people to tell me how much this bug improves "perceived
page loading"...  If there are still a bunch of other problems lurking out
there, meaning that this patch only fixes a small percentage of the problems,
then we might as well pass on the patch...

however, if this patch manages to fix a large percentage of the blank page
loads, then i'd opt to include it - because it should be very low risk (it only
comes into play in the FAILURE case)...

-- rick

Running with the patch, I could reproduce this bug on dict.org just as easily as
I could without it.

hey Chad,
are you running a debug build? or an optimized one?

If it is a debug build, it would be great if you could attach a HTTP log of what 
happens when www.dict.org fails...

-- rick

P.S.
have you tried clearing your cache lately? you could be seeing a different cache 
corruption bug :-)


Optimized, and no, I haven't cleared my cache.  I'll do that now.

I will try to reproduce the bug with a debug build today too.


    
    

    
  
For what it's worth, I disabled the disk and mem cache in my build and can 
still reproduce the bug easily.


    
    

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

    
    

    
  


  

    
    

    
  


  

    
    

    
  
I noticed that the HTTP channel was getting canceled while waiting for a
OnCacheEntryAvailable event.  However, the cancelation wasn't being acknowledged
in OnCacheEntryAvailable.  My v1.1 patch fixes this.

    
    

    
  
dougt says: r/sr=

    
    

    
  
r=bbaetz

    
    

    
  
-> me
Assignee: rpotts → darin
Keywords: patch, 
          
            review
Target Milestone: --- → mozilla0.9.3

    
    

    
  
Cc'ing selmer. Darin is confident that this patch fixes the page loading
problem; Chad is testing.

    
    

    
  
a=dbaron on behalf of drivers for trunk checkin during 0.9.3 closure.
Whiteboard: approved for 0.9.3

    
    

    
  
fixed on the trunk
Status: NEW → RESOLVED
Closed: 23 years ago
Keywords: vtrunk
Resolution: --- → FIXED

    
    

    
  
Does this patch have any impact on the remainder of 82720?  Blake, can you get
to the Mozilla sites without hitting the blank page problem after applying this
patch (and without doing the repeated clicking)?

    
    

    
  
Yup, darin's checkin fixed dict.org for me.

I'll test 82720 now.


    
    

    
  
reopening for checkin on the 0.9.2 branch
Status: RESOLVED → REOPENED
Keywords: topembed
Resolution: FIXED → ---

    
  
Status: REOPENED → ASSIGNED

    
  
Target Milestone: mozilla0.9.3 → mozilla0.9.4

    
  
Whiteboard: approved for 0.9.3 → fixed-on-trunk

    
  
Priority: -- → P1

    
  
Target Milestone: mozilla0.9.4 → ---

    
    

    
  
qa -> me  
QA Contact: benc → tever

    
    

    
  
verified on trunk per reporter
Whiteboard: fixed-on-trunk → verified-on-trunk

    
    

    
  
fixed-on-branch
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: