Closed
Bug 91710
Opened 24 years ago
Closed 24 years ago
opening page several times quickly shows completely blank page
Categories
(Core :: Networking: Cache, defect, P1)
Tracking
()
RESOLVED
FIXED
People
(Reporter: caustin, Assigned: darin.moz)
References
()
Details
(Keywords: topembed, Whiteboard: verified-on-trunk)
Attachments
(6 files)
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
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.
Reporter | ||
Comment 1•24 years ago
|
||
Okay, I just reproduced this in today's commercial branch build. It was harder
to do though. :)
Comment 2•24 years ago
|
||
this is probably the same as a bug that gordon, dougt, and I saw when trying to
reproduce bug 82720.
Comment 3•24 years ago
|
||
Comment 4•24 years ago
|
||
Comment 5•24 years ago
|
||
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...
Comment 6•24 years ago
|
||
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...
Comment 7•24 years ago
|
||
I heard the word 'cache'! ccing gordon.
Component: Networking → Networking: Cache
Comment 8•24 years ago
|
||
Comment 9•24 years ago
|
||
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
Comment 10•24 years ago
|
||
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 :-)
Comment 11•24 years ago
|
||
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)
Comment 12•24 years ago
|
||
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* :-)
Comment 13•24 years ago
|
||
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
Comment 14•24 years ago
|
||
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.
Comment 15•24 years ago
|
||
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
Reporter | ||
Comment 16•24 years ago
|
||
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.
Comment 17•24 years ago
|
||
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
Comment 18•24 years ago
|
||
It was dict.org, with the page source: <html><body></body></html>
Comment 19•24 years ago
|
||
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...
Comment 20•24 years ago
|
||
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?
Comment 21•24 years ago
|
||
Do we know if the patch helps anything yet?
Comment 22•24 years ago
|
||
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
Reporter | ||
Comment 23•24 years ago
|
||
Running with the patch, I could reproduce this bug on dict.org just as easily as
I could without it.
Comment 24•24 years ago
|
||
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 :-)
Reporter | ||
Comment 25•24 years ago
|
||
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.
Reporter | ||
Comment 26•24 years ago
|
||
Reporter | ||
Comment 27•24 years ago
|
||
For what it's worth, I disabled the disk and mem cache in my build and can
still reproduce the bug easily.
Comment 28•24 years ago
|
||
*** Bug 92139 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 29•24 years ago
|
||
Assignee | ||
Comment 30•24 years ago
|
||
Assignee | ||
Comment 31•24 years ago
|
||
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.
Assignee | ||
Comment 32•24 years ago
|
||
dougt says: r/sr=
Comment 33•24 years ago
|
||
r=bbaetz
Assignee | ||
Comment 34•24 years ago
|
||
-> me
Comment 35•24 years ago
|
||
Cc'ing selmer. Darin is confident that this patch fixes the page loading
problem; Chad is testing.
Comment 36•24 years ago
|
||
a=dbaron on behalf of drivers for trunk checkin during 0.9.3 closure.
Whiteboard: approved for 0.9.3
Assignee | ||
Comment 37•24 years ago
|
||
fixed on the trunk
Comment 38•24 years ago
|
||
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)?
Reporter | ||
Comment 39•24 years ago
|
||
Yup, darin's checkin fixed dict.org for me.
I'll test 82720 now.
Assignee | ||
Comment 40•24 years ago
|
||
reopening for checkin on the 0.9.2 branch
Assignee | ||
Updated•24 years ago
|
Status: REOPENED → ASSIGNED
Updated•24 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Assignee | ||
Updated•24 years ago
|
Whiteboard: approved for 0.9.3 → fixed-on-trunk
Assignee | ||
Updated•24 years ago
|
Priority: -- → P1
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9.4 → ---
Comment 42•24 years ago
|
||
verified on trunk per reporter
Whiteboard: fixed-on-trunk → verified-on-trunk
Assignee | ||
Comment 43•24 years ago
|
||
fixed-on-branch
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•