[Webkit-unassigned] [Bug 22700] ApplicationCache should have size limit

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Apr 30 05:12:55 PDT 2009


https://bugs.webkit.org/show_bug.cgi?id=22700


andreip at google.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #29883|0                           |1
        is obsolete|                            |




------- Comment #8 from andreip at google.com  2009-04-30 05:12 PDT -------
Created an attachment (id=29909)
 --> (https://bugs.webkit.org/attachment.cgi?id=29909&action=view)
New proposal to limit the maximum size of the application cache (take 4).

While poking around the existing code, I found a bug that can cause a crash:

- in ApplicationCacheGroup.cpp:736 we have:

(...)
cacheStorage().storeNewestCache(this, maxAppCacheSize());
if (oldNewestCache)
    cacheStorage().remove(oldNewestCache.get());
postListenerTask(someSuccessCallback);
(...)

The problem with this is that the return value of
cacheStorage().storeNewestCache() is never checked. If it fails (e.g. the
user's data partition if full), the code should fire an error event and bail
out. Instead, the existing newest cache is wiped out, thereby leaving an orphan
cache group in the CachedGroups table. This orphan cache group now points to a
non-existing "newest cache" so next time this group will be loaded, there will
be no associated manifest resource and an assertion will fire in
applicationcachegroup.cpp:597:

ApplicationCacheResource* newestManifest = m_newestCache->manifestResource();
ASSERT(newestManifest);

Rather than creating a separate bug for this, I thought I'd fix it in the same
patch.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list