Title: [183896] trunk/Source/WebKit2
- Revision
- 183896
- Author
- beid...@apple.com
- Date
- 2015-05-06 16:05:38 -0700 (Wed, 06 May 2015)
Log Message
Crash executing null AsyncRequest in IDB code.
<rdar://problem/18854856> and https://bugs.webkit.org/show_bug.cgi?id=144715
Reviewed by Darin Adler.
When UniqueIDBDatabase fails to execute an operation on the database work queue it usually
dispatches an AsyncRequest ID back to the main thread with an error callback.
For two of its operations it would then also dispatch the success callback.
In those cases the main thread would first take the AsyncRequest for the error callback out
of a map and then execute it.
It would then try to take the same AsyncRequest out of the map again, fail to do so, then
execute a null AsyncRequest.
This patch fixes the two functions to not dispatch both an error and success callback.
* DatabaseProcess/IndexedDB/UniqueIDBDatabase.cpp:
(WebKit::UniqueIDBDatabase::countInBackingStore): Return after dispatching the error callback.
(WebKit::UniqueIDBDatabase::deleteRangeInBackingStore): Ditto.
Modified Paths
Diff
Modified: trunk/Source/WebKit2/ChangeLog (183895 => 183896)
--- trunk/Source/WebKit2/ChangeLog 2015-05-06 22:55:09 UTC (rev 183895)
+++ trunk/Source/WebKit2/ChangeLog 2015-05-06 23:05:38 UTC (rev 183896)
@@ -1,3 +1,27 @@
+2015-05-06 Brady Eidson <beid...@apple.com>
+
+ Crash executing null AsyncRequest in IDB code.
+ <rdar://problem/18854856> and https://bugs.webkit.org/show_bug.cgi?id=144715
+
+ Reviewed by Darin Adler.
+
+ When UniqueIDBDatabase fails to execute an operation on the database work queue it usually
+ dispatches an AsyncRequest ID back to the main thread with an error callback.
+
+ For two of its operations it would then also dispatch the success callback.
+
+ In those cases the main thread would first take the AsyncRequest for the error callback out
+ of a map and then execute it.
+
+ It would then try to take the same AsyncRequest out of the map again, fail to do so, then
+ execute a null AsyncRequest.
+
+ This patch fixes the two functions to not dispatch both an error and success callback.
+
+ * DatabaseProcess/IndexedDB/UniqueIDBDatabase.cpp:
+ (WebKit::UniqueIDBDatabase::countInBackingStore): Return after dispatching the error callback.
+ (WebKit::UniqueIDBDatabase::deleteRangeInBackingStore): Ditto.
+
2015-05-06 Dean Jackson <d...@apple.com>
Handle backdrop views that have to tile
Modified: trunk/Source/WebKit2/DatabaseProcess/IndexedDB/UniqueIDBDatabase.cpp (183895 => 183896)
--- trunk/Source/WebKit2/DatabaseProcess/IndexedDB/UniqueIDBDatabase.cpp 2015-05-06 22:55:09 UTC (rev 183895)
+++ trunk/Source/WebKit2/DatabaseProcess/IndexedDB/UniqueIDBDatabase.cpp 2015-05-06 23:05:38 UTC (rev 183896)
@@ -1042,6 +1042,8 @@
if (!m_backingStore->count(transactionIdentifier, objectStoreID, indexID, keyRangeData, count)) {
LOG_ERROR("Failed to get count from backing store.");
postMainThreadTask(createAsyncTask(*this, &UniqueIDBDatabase::didCountInBackingStore, requestID, 0, IDBDatabaseException::UnknownError, ASCIILiteral("Failed to get count from backing store")));
+
+ return;
}
postMainThreadTask(createAsyncTask(*this, &UniqueIDBDatabase::didCountInBackingStore, requestID, count, 0, String(StringImpl::empty())));
@@ -1060,6 +1062,8 @@
if (!m_backingStore->deleteRange(transactionIdentifier, objectStoreID, keyRangeData)) {
LOG_ERROR("Failed to delete range from backing store.");
postMainThreadTask(createAsyncTask(*this, &UniqueIDBDatabase::didDeleteRangeInBackingStore, requestID, IDBDatabaseException::UnknownError, ASCIILiteral("Failed to get count from backing store")));
+
+ return;
}
m_backingStore->notifyCursorsOfChanges(transactionIdentifier, objectStoreID);
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
