193454 - Caching fails when _CACHE_MAP_ is corrupted

Status: RESOLVED DUPLICATE of bug 229984

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

Description

[Warner Young]

I don't know what caused it to begin with, but I'm guessing something in my disk
cache files is corrupted.  No matter what my disk cache size settings are,
about:cache will report 0 entries, and 469849856 bytes in use.  I will attach a
screenshot of my about:cache report.

This is on build 2003021308, Win98 SE.  I think the cache has been this way for
a little while, and I only noticed now.  This is the second time I've seen this,
and the first time, deleting all files in the cache directory fixed the problem.
 I will keep the current (corrupted?) files for now, in case someone needs to
look at them.

Comment 1

[Warner Young]

Attachment: Screenshot of about:cache info

Comment 2

[NilsE]

Confirming this on 1.3b (linux), setting OS to all.

I just noticed today that files were reloaded over the network that should have
been in cache. My about:cache:

Disk cache device

Number of entries: 	0
Maximum storage size: 	10240000 Bytes
Storage in use: 	1207959552 Bytes

Oops. The cache directory looks like this:

... 35328 Feb 17 18:06 _CACHE_001_
... 53248 Feb 17 18:04 _CACHE_002_
... 69632 Feb 17 18:03 _CACHE_003_
... 135168 Feb 17 13:34 _CACHE_MAP_

A bit small alltogether ...

Comment 3

[Andrew Hagen]

This is apparently a recent regression. Reporters, if you switch to 1.3 alpha,
do you still see this problem?

This should block 1.3, as it is a recent regression.

Comment 4

[Warner Young]

Andrew, switching to an older version (I tried 1.3a and also the official 1.2.1)
doesn't help.  With each version, I surfed to a few sites first, but about:cache
still shows incorrect info and apparently no caching going on.

In addition, using the Clear Disk Cache button in Preferences doesn't help.

Comment 5

[Andrew Hagen]

Okay, thank you for checking. That means it isn't terribly needed for 1.3.
Withdrawing nomination. Removing regression keyword, though this could still be
a regression from the 1.0 branch.

I wonder which file is corrupted. Maybe the cache_001 file? Reporter, could you
rename each of the files, and, in turn, test Mozilla after each renaming to see
which one is causing the problem?

Comment 6

[Warner Young]

Andrew, I tried renaming each file.  The only one that produced good results
(cache working again) was the _CACHE_MAP_ file.  Should I zip this up and attach it?

Comment 7

[Andrew Hagen]

Great! Yes, please do so.

Comment 8

[Warner Young]

Attachment: ZIP file of corrupted _CACHE_MAP_ file

Comment 9

[Mikkel Lauritsen]

I see this as well with yesterdays build (20030219) on Windows 2000.
My about:cache says

Number of entries: 	0
Maximum storage size: 	51200000 Bytes
Storage in use: 	1075776768 Bytes

Wrt. comments #3 and #5, I believe that the regression keyword should
be set and that this is a blocker since caching isn't working at all.
I'm sure that I did _not_ see this on 1.2.1; the first time I noticed
that caching wasn't working was after installing 1.3b.

Comment 10

[gordon]

Darin, here's an example of some of the bugs I've been seeing recently.  I hope
to get to them in the next week, but if you have any ideas off the top of your
head, I'd love to hear them.

Comment 11

[Darin Fisher]

gordon: build 2003021308 would not have my changes for bug 176919, so this must
be something else.  sorry, i'm not sure what's going on.  adding topembed..

Comment 12

[Mikkel Lauritsen]

Just as a clarification to comment #9, this problem started when I installed 1.3b
on top of 1.2.1 without uninstalling. I haven't tried reproducing this bug on a
clean 1.3b install, and as implicated by comment #6, removing all files from the
cache directory makes caching work again.

Comment 13

[Darin Fisher]

nevermind comment #11... i miss read the build id :-/

Comment 14

[Matt]

Hi, I reported bug 202621 which appears to be a dup of this. I'll add some
detail: I was able to fix the behavior simply by renaming the cache directory so
Mozilla would start over. The directory contained the following files:
_CACHE_001_
_CACHE_002_
_CACHE_003_
_CACHE_MAP_
1CCD06C5d01

Each of the "cache" files were well under the 5000 KB limit I'd set in prefs.
The strangely named one was 31,250. I've still got the files, if anyone wants
them or needs me to do a little testing.

Comment 15

[Warner Young]

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

Comment 16

[saari (gone)]

topembed-

Comment 17

[Samir Gehani]

adt: nsbeta1-

Comment 18

[NilsE]

Haven't seen this since 1.3. No incident with any of the 1.4 (betas/final).
Probably silently fixed by other checkin. Should this be a WFM by now?

Comment 19

[Brian Rogers]

I just got corrupted cache in 1.6a.  I was viewing some Flash animatins, and
noticed that they were reloading from the network.  Eventually the animation
froze and then Mozilla crashed.  I relaunched Mozilla, went to about:cache, and
found that only the memory cache was listed.  I checked noticed that Mozilla
deleted the cache folder.  So after closing and starting Mozilla again, the
problem was solved.

But, I'm setting this to critical because of the crash.

Comment 20

[Matthias Versen [:Matti]]

You got a crash and Mozilla deleted the cache (it always does this after a crash)

Comment 21

[Warner Young]

Matti, I think burpmaster meant that he felt Mozilla crashed *because* he got
corrupted cache files to begin with, and that's why he set it to critical.  For
what it's worth, I saw this again recently, but I had no good way to check
whether the corruption actually occurred recently, or whether I only *noticed*
it recently.

Comment 22

[WD]

I recently filed bug 229746

I had a couple of system crashes due to a bad driver, and I ran into the problem
of Mozilla not using the disk cache.   The thing is, it seems that Mozilla did
not delete the cache after the crash, and that's why the cache stopped working.

Comment 23

[Warner Young]

Based on WD's comments, I'll mark this a dupe of bug 229984.

*** This bug has been marked as a duplicate of 229984 ***