277473 - Clearing cache results in 4194303 KiB Storage in use displayed in about:cache

Status: RESOLVED WORKSFORME

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

Description

[Steve Chapel]

Reproducable: Always

Steps to Reproduce:
1. Go to URL about:cache
2. Clear the cache
3. Reload the about:cache page

Expected Results: Memory cache storage in use is displayed as 0 KiB
Actual Results: Memory cache storage in use is displayed as 4194303 KiB

I can reproduce reliably in Mozilla 1.8a5 on Windows XP SP2, and others have
reproduced it in Firefox 1.0. It's purely a cosmetic problem, since the memory
cache continues to function normally, and the only way to see the 4 GiB figure
is to have the about:cache page already visible and reload it immediately after
clearing the cache.

Comment 1

[Steve Chapel]

I get the expected results in Mozilla trunk build 2005010711.

Comment 2

[Steve Chapel]

I reproduced this bug in Mozilla 1.8a6, so reopening. It's reproducable only
sometimes, though.

Comment 3

[Alfred Kayser]

Found the issue:
in nsMemoryCacheDevice.cpp, the total count (mTotalSize) is incremented with the
DataSize() of the object, but decremented with the 'Size()', which also includes
the size of the metadata of that object. For memory object there is generally no
metadata, but some things (like http://www.ibm.com/uc.gif?src=script) there is
some metadata...

Comment 4

[Alfred Kayser]

Attachment: Fix mTotalSize accounting (by only using 'DataSize')

Fix to get correct accounting in mTotalSize. Also merged 'AdjustMemoryLimits'
with 'SetCapacity' for simplicity.

mTotalSize is incremented through 'OnDataSizeChange', which only accounts for
the data part of cached objects and not for the meta size (which is generally,
but not allways, zero).
mTotalSize was decremented at deactivation/dooming by 'Size()' which includes
the metadata size...

So, this patch changes all mTotalSize accounting to just DataSize().
This makes it at least the accounting in itself consistent.

Note, the same problem may apply to the diskcache?

Comment 5

[Darin Fisher]

I'm confused.  Don't we want to count the meta data as part of the memory
allocated for a cache entry?

Comment 6

[Alfred Kayser]

In theory yes, but how can the memory cache device track metadata size changes?
There seems to be no way that the memory cache device is notified when there are
metadata changes, like OnDataSizeChange for data...

Comment 7

[Darin Fisher]

OK, perhaps the memory cache should look at nsCacheEntry::Size() again when the
entry is closed.  I think we need to find a way to track the meta data because
that can be a significant portion of the cache entry, especially for small images.

Comment 8

[Alfred Kayser]

If we make SetMetaDataElement of nsCacheEntry to call OnMetaSizeChange of
mCacheDevice then also the MetaData size can be tracked in mTotalSize of the
Memory cache. 
May be best to track mTotalDataSize and mTotalMetaSize seperately for convenience?

Comment 9

[mudler]

I'm using:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

The bug is still reproducable 100% of the time.  I am using the vanilla build from mozilla, haven't used the patch.

Is there any intention to either have the patch listed here merged with the trunk for bon echo, or have other alternative fixes merged if it hasn't been done already?  I haven't used the bon echo alphas yet so wouldn't know.

Comment 10

[Darin Fisher]

(In reply to comment #8)
> If we make SetMetaDataElement of nsCacheEntry to call OnMetaSizeChange of
> mCacheDevice then also the MetaData size can be tracked in mTotalSize of the
> Memory cache. 
> May be best to track mTotalDataSize and mTotalMetaSize seperately for convenience?

Alfred, if tracking both separately makes it simpler, then by all means... but if it is possible to re-use the same counter, then that would be even better :)

Comment 11

[Darin Fisher]

-> reassign to default owner

Comment 13

[Jo Hermans]

I think this is fixed in 3.1b1, but I haven't found back that bug.

Comment 14

[Alfred Kayser]

Probably by Bug 430061 -  Replace imglib's use of necko memory cache with an imglib-specific cache.
As the images are now not in memory cache anymore, the memory cache is not used as much, and won't have this behaviour easily but it can still happen.
The problem is that the accounting of object size is not precise (meta data is not always correctly accounted for). See comment #3.

Comment 15

[:aceman]

Still not fixed in Firefox 5 on Win XP. It happens for me after toggling Permanent private browsing mode in Options. The number is bogus. But after a while, probably storing something into the empty caches makes the number show correct values.

Comment 17

[Mihai Morar, (:MihaiMorar)]

Fixed on Latest Nightly 25.