[Webkit-unassigned] [Bug 226814] localStorage "locks" items when they're updated too frequently

[bugzilla-daemon at webkit.org]

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

--- Comment #21 from Chris Dumez <cdumez at apple.com> ---
(In reply to Pascal Cremer from comment #20)
> (In reply to Chris Dumez from comment #19)
> > Good news. Pascal was able to provide me with a test case and I determined
> > that this was fixed recently on trunk by
> > https://trac.webkit.org/changeset/278651.
> > 
> > Given the patch, I suspect we had a quota accounting issue and we were
> > refusing the do writes thinking that the quota was reached. I'll look into
> > this more tomorrow to see if I can spot the logic issue.
> > 
> > In any case, it appears to be fixed.
> 
> Thanks Chris, really appreciate you've dedicated some time to investigate.
> 
> Would be great if you could share your any findings, since I'm still trying
> to wrap my head around on how I could reach the exception state with the
> snippet from my start post.

It was an accounting issue on our side. In particular, this code in setItem():
```
        if (!m_databaseSize) {
            m_databaseSize = SQLiteFileSystem::databaseFileSize(m_databasePath);
        }
        CheckedUint64 newDatabaseSize = *m_databaseSize;
        newDatabaseSize -= oldValue.sizeInBytes();
        newDatabaseSize += value.sizeInBytes();
```

I see that oldValue.sizeInBytes() can be larger than newDatabaseSize. As a result, `newDatabaseSize -= oldValue.sizeInBytes()` would underflow and we'd end up with a very large newDatabaseSize (over quota). Mixing string sizes in bytes and database size on disk was not a good idea.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210616/64554e69/attachment.htm>