Bug 226295

Summary: Abandon pending tasks on background thread when WebIDBServer is closed
Product: WebKit Reporter: Sihui Liu <sihui_liu>
Component: WebKitGTKAssignee: Sihui Liu <sihui_liu>
Status: RESOLVED FIXED    
Severity: Normal CC: alecflett, beidson, benjamin, bugs-noreply, cdumez, cmarcelo, ews-watchlist, ggaren, jsbell
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
ews-feeder: commit-queue-
Patch
none
Patch
ews-feeder: commit-queue-
Patch none

Sihui Liu
Reported 2021-05-26 14:37:43 PDT
Potential fix for rdar://77532291.
Attachments
Patch (5.94 KB, patch)
2021-05-26 20:47 PDT, Sihui Liu
ews-feeder: commit-queue-
Patch (5.99 KB, patch)
2021-05-26 23:02 PDT, Sihui Liu
no flags
Patch (6.03 KB, patch)
2021-05-27 09:06 PDT, Sihui Liu
ews-feeder: commit-queue-
Patch (7.39 KB, patch)
2021-05-27 10:07 PDT, Sihui Liu
no flags
Sihui Liu
Comment 1 2021-05-26 20:47:26 PDT
Chris Dumez
Comment 2 2021-05-26 20:55:37 PDT
Comment on attachment 429839 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=429839&action=review > Source/WTF/ChangeLog:8 > + Make the wait ends with either a new message or queue being killed. Ends -> end > Source/WebKit/ChangeLog:9 > + tasks. We can ditch them by killing the CrossThreadQueue. For ongoing task, it can be blockd on quota check, so Typo: blockd > Source/WebKit/NetworkProcess/IndexedDB/WebIDBServer.cpp:425 > + callOnMainRunLoop([protectedThis = WTFMove(protectedThis)]() mutable { }); Do we really need the mutable? > Source/WebKit/NetworkProcess/IndexedDB/WebIDBServer.cpp:436 > m_closeCallback(); Is it ok to call the close callback before we’ve actually asynchronously done it? > Source/WebKit/NetworkProcess/IndexedDB/WebIDBServer.h:101 > + std::unique_ptr<WebCore::IDBServer::IDBServer> m_server WTF_GUARDED_BY_LOCK(m_serverLock); Nice :)
Sihui Liu
Comment 3 2021-05-26 23:00:45 PDT
Comment on attachment 429839 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=429839&action=review >> Source/WebKit/NetworkProcess/IndexedDB/WebIDBServer.cpp:425 >> + callOnMainRunLoop([protectedThis = WTFMove(protectedThis)]() mutable { }); > > Do we really need the mutable? Nope >> Source/WebKit/NetworkProcess/IndexedDB/WebIDBServer.cpp:436 >> m_closeCallback(); > > Is it ok to call the close callback before we’ve actually asynchronously done it? Yes, this currently is just removing itself from the map of Network process and we keep the reference with CompletionCallback above.
Sihui Liu
Comment 4 2021-05-26 23:02:10 PDT
Sihui Liu
Comment 5 2021-05-27 09:06:03 PDT
Chris Dumez
Comment 6 2021-05-27 09:11:08 PDT
Comment on attachment 429883 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=429883&action=review > Source/WebCore/ChangeLog:9 > + abort transactions on the main thread. Why is it safe then? There is no guarantee that SQLite is built with thread-safety support enabled or that SQLite mutexes are fully enabled at runtime.
Sihui Liu
Comment 7 2021-05-27 09:52:06 PDT
(In reply to Chris Dumez from comment #6) > Comment on attachment 429883 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=429883&action=review > > > Source/WebCore/ChangeLog:9 > > + abort transactions on the main thread. > > Why is it safe then? There is no guarantee that SQLite is built with > thread-safety support enabled or that SQLite mutexes are fully enabled at > runtime. Tasks on the background thread need to acquire the lock for m_server to perform database operations. They acquire the lock at start, release the lock before performing quota check (which may be blocked on waiting user permission), and acquire the lock again after it.
Sihui Liu
Comment 8 2021-05-27 10:07:03 PDT
Chris Dumez
Comment 9 2021-05-27 11:36:52 PDT
Comment on attachment 429892 [details] Patch r=me
EWS
Comment 10 2021-05-27 14:55:48 PDT
Committed r278179 (238222@main): <https://commits.webkit.org/238222@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 429892 [details].
Note You need to log in before you can comment on or make changes to this bug.