We avoid the race by cloning the file before calling GetParent, to avoid
writing to mCacheDirectory's buffer on the main thread during shutdown,
when called from SyncRemoveAllCacheFiles.
Additionally, we dispatch OnDelayedStartupFinished to the IO thread
to avoid accessing mCacheDirectory on the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D155798
This patch uses a CachePurgeLock for every directory it deletes.
Because we can't possibly know if a folder was already deleted before we
aquire the lock or if it never existed (without the use of a log file) we
can assume that if a folder isn't there after the timeout has expired it's
already been purged by a different cleanup task.
Depends on D132164
Differential Revision: https://phabricator.services.mozilla.com/D132165
Purge HTTP disk cache using backgroundtasks
Motivation:
In the History settings preferences panel you may choose to
`Clear History when Firefox closes` - which sets the
`privacy.sanitize.sanitizeOnShutdown` pref.
If the `Cache` checkbox is also checked it sets the
`privacy.clearOnShutdown.cache` pref to true.
When both of these prefs are true `CacheObserver::ClearCacheOnShutdown()`
will return true, which will cause Firefox to clear the HTTP disk cache
during shutdown. This will block shutdown for howeverlong this takes. If the
user has a slow disk, or the user is on Windows and something is blocking the
deletion of those files, this will trigger a shutdown hang making Firefox
crash. This leads to a bad user experience as trying to start Firefox again
during this time will show the "Firefox is already running message".
Eventually a crash dump is produced. Bug 1356853 and bug 1682899 are caused
by this specific issue.
In order to avoid these crashes and a bad user experience we have
a few options:
1. Completely disable the disk cache when a user checks this box.
This option will degrade the user's browsing experience.
2. Don't delete the folder at shutdown
Whether we do this by removing the checkbox or simply not respecting
the pref value, users who already have this setting would be surprised
if the cache folder stops being deleted.
3. Use a thread pool to delete the files
While it's likely to speed up the deletion at least a little bit,
this would introduce additional complexity while not completely
fixing the issue. A slow disk will still block shutdown.
4. Delete the cache at shutdown using a separate process
This is likely the best option. It has the advantage of not blocking
shutdown while at the same time maintaining similar properties to the
existing functionality:
- The cache folder is deleted at shutdown.
- Has the same behaviour if Firefox gets killed or crashes for different issues.
- Behaves similarly if the OS is forcefully shutdown during or before we begin to purge.
- Additionaly, because we rename the folder prior to dispatching the background task, if the purging isn't completed we
- don't rebuild the cache from an incomplete folder on next restart
- are able to resume the purging after Firefox startup
A particularly special case is the Windows shutdown.
If the user shuts down windows that will try to close Firefox. If the shutdown
takes too long, the user will see the "Close anyway" button and may click
it thus preventing the cache purge to complete.
When using a background task we have a similar situation, but the button won't
even appear. So after the next Firefox restart we will check if the cache
needs to be purged.
Largely, the new behaviour will be:
- At shutdown we conditionally dispatch a background task to delete the folder
- If creating the process fails (for some reason) we fallback to the old way
of synchronously deleting the folder.
- The task will then try to delete the folder in the background
- If for some reason it fails, we will dispatch a new background task shortly
after Firefox restarts to clean up the old folders.
Differential Revision: https://phabricator.services.mozilla.com/D126339
In CacheFileIOManager::GetEntryInfo(), there is only a problem if the Alt Data
element is present but we can't parse a reasonable value out of it (a value
smaller than the metadata offset).
Differential Revision: https://phabricator.services.mozilla.com/D146467
The idea in this patch is like D99680, but the difference is that mFrecencyArray now contains CacheIndexRecordWrapper.
This should be able to help us track why CacheIndexRecordWrapper is released before removing it from mFrecencyArray.
Differential Revision: https://phabricator.services.mozilla.com/D139469
-Wshadow warnings are not enabled globally, so these -Wno-shadow suppressions have no effect. I had intended to enable -Wshadow globally along with these suppressions in some directories (in bug 1272513), but that was blocked by other issues.
There are too many -Wshadow warnings (now over 2000) to realistically fix them all. We should remove all these unnecessary -Wno-shadow flags cluttering many moz.build files.
Differential Revision: https://phabricator.services.mozilla.com/D132289
Mark Banner
Manuel Bucher
Valentin Gosu
edguloien
Dana Keeler
Narcis Beleuzu
Bryan Thrall
Fabrice Desré
Andreea Pavel
Serge Guelton
Mike Hommey
Jan Rio Krause
Randell Jesup
Noemi Erli
Butkovits Atila
Kershaw Chang
Marian-Vasile Laza
Chris Peterson
Sandor Molnar
Csoregi Natalia
Paul Zuehlcke