Communicator clears the cache before it gets full

1. What's the problem?

I'm surfing. Suddenly a message appears at the bottom of the window: 'Cache clearing: removing xxxx files'. All the files at cache disappear.

This is a bad thing, when you pay for telephone time and are looking for information: you must reload all the pages.

1.1. Is the problem solved? (05/06/98)
I don´t know. I download the last Mozilla files and, now, I cann´t reproduce the effect in the same way I used to. I only can wait to:
    a) Communicator 4.5    Perhaps the problem is solved.
    19/11/98 Not resolved. Waiting for ...
    b) Another trigger site

2. Is it only my problem?

Not only mine, I had seen several users complaint about it at netscape.communicator news group

3. Reproduce

Since I am not able, yet, to discover why the memory get corrupted, as explained later, I only can reproduce it in a purely empiric way.

To reproduce it you must go to a certain fat.db situation. Then you must go to a certain sites that provokes the clearing.

I have luck: I have a fat.db previous to the clearing. You can get it here (zip file70K).
Close Communicator and copy this file to the cache directory of your test user
Open Communicator and, first, go to clear disk cache at Preferences.
And the combination of sites you must follow to see the effect is:
    First go to http://my.excite.com/computers_and_internet/internet/
    There, click on Netscape Communicator or Microsoft Explorer? on the Talk section
    Click Back button on Navigator

Clearing goes here after it. I probe it at three computers. And a different person test it too, with the same effect.

4. Is fat.db corrupted?

Copy again the fat.db file to the cache directory.
Open Communicator and at location bar write: about:cache?traceon

There is no error message, therefore Communicator have a correct fat.db

4.1. Yes. The fat.db is corrupted. (Thanks Ten Thumbs) (28/06/98)
The header for your fat.db says there's 1162 items in the database, but you can retrieve 1172. This certainly looks like a corrupt database but I suspect the real problem happened before the failure.
Well, therefore, is corrupted. However, you can surf with it and Communicator seems to have no problem with it .... until you go to a death sequence. (see 1.1.)

5. When the bug comes?

I download Mozilla files and build it. The feature is still there. I track down the moment of the problem.

When you hit the back button, Mozilla sees that the page has expired. Then it try to remove the previous page objects, one of them the URL at cache.

These are the routines and the final final line where the problem comes:

NET_RemoveURLFromCache mkcache.c
hash_delete hash.c
hash_access hash.c
__delpair h_page.c

memmove(dst, src, length) The line

6. What is bad?

For some reason, I am now looking for it yet, that memory movement overwrites the file length Mozilla is trying to load. The size resultant is a big number. Mozilla thinks cache is full and clear it.

More explicit:

At Net_RemoveURLFromCache there is a variable named data. This is a structure with two fields: data and size. The data field points to a memory zone that in its 20th position has the file size.

In this routine, at the return from the call to:

(*local_cache_database->del)(local_cache_database, key, 0);

the memory zone pointed by data->data has been overwrited.

7. Status of investigation

net_GetInt32InCacheDBT => Size calculated: 17545

Routine hash_access
HASH_DELETE
Buffer: 00A86550
rbufp->page: 01AB64F0 rbufp->flags: 12 bp: 01AB64F2 bp[1]: 0 n: 2 ndx: 1 Hash ovflpage
rbufp->page: 00358FD8 rbufp->flags: 1 bp: 00358FDA bp[1]: 3860 n: 4 ndx: 1 Found:
HASH_DELETE

Routine Delpair
hashp: 01A8E7F8 bufp: 009ACB20 ndx: 1
bp: 00358FD8
n: 4
bp[ndx+1]: 3860
newoff: 4096
pairlen: 236
Hard case
src: 00359E0C
dst: 00359EF8
dst_offsett: 3872
length: 224

Going out:
n: 4
bp[n]: 3872
bp[n-1]: 3862
bp[0]: 2

net_GetInt32InCacheDBT => Size calculated: 869135666

Next step:
Who save these values at buffer page? Trying to look at HASH_PUT routines.

Hosted by www.Geocities.ws