Closed Bug 1309695 Opened 6 years ago Closed 6 years ago

Firefox Developer - cache keeps getting cleared on shutdown

Categories

(Core :: Networking: Cache, defect)

51 Branch
x86_64
Windows 10
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1311271

People

(Reporter: me, Assigned: mayhemer)

Details

(Whiteboard: [necko-active])

Attachments

(1 file)

1.13 MB, application/x-zip-compressed
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20161012004014

Steps to reproduce:

Clean profile and install

Do some browsing, build up a cache.

Close browser

Do some more browsing



Actual results:

The cache is cleared after a few seconds into the next session.
Tried with fresh install of 51.0a2 (2016-10-12) (64-bit) and clean profile. 
The cache folder within the profile is emptied.


Expected results:

Cache should be retained until either manually cleared or items evicted.
Severity: normal → major
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Hey Mark,

I have tested this on Firefox 51.0a2 [aurora]. The cache folder within the profile is not emptied. Here is the screen capture: https://testing-1.tinytake.com/sf/MTA1NDE1Nl80MjY0NzQ3

If it is still reproducible to you, could you please provide the url for the pages you were browsing ?  Any additional information is appreciated.  Thanks

---
Version 	51.0a2
Build ID 	20161017004013
Update Channel 	aurora
User Agent 	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Component: Untriaged → Networking: Cache
Product: Firefox → Core
Flags: needinfo?(me)
Reporter, 

"The cache folder within the profile is emptied" - which folder is that exactly?  Just to make sure that what you are looking at is really the folder of the HTTP cache location for the profile you use.

Is the folder completely empty when this bug happens?


Honestly, this sounds a bit strange.  We didn't make any recent change (AFAIK) that would affect exactly this in Dev Edition.  Tho, I will check the logs.
Severity: major → normal
Could you also provide a log from a session you observe this behavior at?  Please read https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging 

Please change the log modules to:

MOZ_LOG_MODULES=cache2:5,sync,timestamp

Thanks.  I suspect this could be related to some changes we made to http cache shutdown (bypass pending writes to avoid slow shutdown when on slower storage device).  We may then find some (most) entries in a broken state and delete them.

If confirmed, this is either a WONTFIX or we may try to increase the shutdown delay time.  Anyway, there are more plans on how we are going to use the http cache on slower storage devices.
Assignee: nobody → honzab.moz
Whiteboard: [necko-active]
Hello All,

right, here is a youtube grab of it happening:

https://youtu.be/K1MdBfP4LqU

so, i've got about:config to use cache2, cache size is set to 1gb. the cache never grows to more than a few hundred items before it disappears. I've also notice everything vanish whilst in use. 

the reason i noticed it was because my internet experience suddenly felt slow and I noticed frequently visited pages were having bits of graphics re-fetched.

the folder is the active cache folder for my profile - you can see it change. it does not matter which site you visit. it always happens.
Mark, please follow instructions in comment 3.
Attached file HTTP Logging File
Here is the HTTP log, as requested in post #3.

You can see the issue occurs at just after 19:19 utc, and if you scroll right to the bottom of the file, you see the deletions.
Flags: needinfo?(me)
The cache seems to be evicted due to this call:
  CacheStorageService::DoomStorageEntries [context=O^userContextId=5,]

IIUC, CacheIndex doesn't understand userContextId attribute, so it behaves like no context was specified.
Thanks Mark and Michal.  This is then duplicate of bug 1311271 which I'm going to fix soon.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1311271
You need to log in before you can comment on or make changes to this bug.