Cache gets corrupted very quickly, breaking web pages

RESOLVED WORKSFORME

Status

()

Core
Networking: Cache
RESOLVED WORKSFORME
11 years ago
2 years ago

People

(Reporter: bz, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

I've been seeing this for a while, but thought I was the only one.  Biesi says he's seen something like this too.  I _think_ I might have even seen this before 1.8 branched, but it's gotten a LOT worse since.

In my daily browsing, a number of sites (lxr, slashdot, NYTimes) seem to have cache corruption issues.  The symptoms for NYTimes are that the stylesheets do not load, for lxr that the content is truncated or that I get an error page claiming that "there was an error", and for slashdot that the only thing that shows is a gray screen.  In all cases, the issue is fixed by a shift-reload... until a few loads later.  For slashdot and NYTimes usually for just the one load I shift-reload; for lxr it sees to work a bit better.  Clearing the cache completely helps better; I might get a day or two of browsing in before things break again.

If this is at all more general than just me we should really look into fixing this.
Flags: blocking1.9?
OK, so this is not a cache issue, at least not for me. DOM Inspector shows all the content (and so does view source, but of course it's not impossible that that re-requested the page).
I couldn't reproduce this in a debug build/layout debugger, but could this warning have to do with this bug?
WARNING: recurring into frame construction: 'mPresContext->mLayoutPhaseCount[eLayoutPhase_FrameC] == 0', file ../../dist/include/layout/nsPresContext.h, line 924

I get it a few times on pages that tend to show this bug.
> but could this warning have to do with this bug?

Maybe, but that warning can happen for all sorts of "safe" reasons (e.g. it'll happen on any page with a text control).  So....
Hmm.  So I just got the slashdot thing again, and tried resizing the window (because someone claimed that that had fixed things of this sort for them).  And indeed, resizing the window works.  So perhaps the NYTimes and Slashdot issues are separate....

Updated

11 years ago
Assignee: nobody → dcamp

Comment 5

11 years ago
Not blocking based on low reproducability, though we should watch for cache issue during beta cycles.
Flags: blocking1.9? → blocking1.9-

Comment 6

11 years ago
My wife's system has had this problem for several months now, on a current patch level XP Pro.  Currently running Firefox 2.0.0.5, previous versions (at least 2.0.0.4) impacted as well.  Clearing her cache or a forced reload will resolve the issue until the next day, when images on various web sites will go missing again.  If I attempt to load the image directly (via right click), firefox reports the image as missing from the web site, using the 404 text.  I suspect there is some cache corruption, where the image/css/component is marked as being in the cache, but is not there when retrieval is attempted.

I'm prepared to do some packet sniffing via my firewall the next time she starts up her system, to see what is going on.  Suspicions are that there is no HTTP request involved, that the fault is entirely in the cache management.
bz: Is this still an issue ?
I didn't got any cache problems in the last year
I haven't seen this in a while, but I also haven't been on Linux in a while...

Updated

5 years ago
Assignee: dcamp → nobody
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.