Title: [144135] trunk/Source/WebCore
Revision
144135
Author
[email protected]
Date
2013-02-26 18:51:44 -0800 (Tue, 26 Feb 2013)

Log Message

SQLTransactionBackend::doCleanup() should not nullify its current
statement and transaction error fields.
https://bugs.webkit.org/show_bug.cgi?id=110826.

Reviewed by Geoffrey Garen.

The reason for this is because the frontend SQLTransaction may have
tasks that are already registered via callOnMainThread(), and may
invoke transaction state functions that access these objects in the
SQLTransactionBackend. This proves to be problematic if the database
was interrupted resulting in doCleanup() being called concurrently
while those states are executing.

Instead, we leave their clean up to the SQLTransactionBackend destructor
which is guaranteed to only be called when the SQLTransaction is also
destructing i.e. these objects are no longer needed.

No new tests.

* Modules/webdatabase/SQLTransactionBackend.cpp:
(WebCore::SQLTransactionBackend::doCleanup):

Modified Paths

Diff

Modified: trunk/Source/WebCore/ChangeLog (144134 => 144135)


--- trunk/Source/WebCore/ChangeLog	2013-02-27 02:40:29 UTC (rev 144134)
+++ trunk/Source/WebCore/ChangeLog	2013-02-27 02:51:44 UTC (rev 144135)
@@ -1,3 +1,27 @@
+2013-02-26  Mark Lam  <[email protected]>
+
+        SQLTransactionBackend::doCleanup() should not nullify its current
+        statement and transaction error fields.
+        https://bugs.webkit.org/show_bug.cgi?id=110826.
+
+        Reviewed by Geoffrey Garen.
+
+        The reason for this is because the frontend SQLTransaction may have
+        tasks that are already registered via callOnMainThread(), and may
+        invoke transaction state functions that access these objects in the
+        SQLTransactionBackend. This proves to be problematic if the database
+        was interrupted resulting in doCleanup() being called concurrently
+        while those states are executing.
+
+        Instead, we leave their clean up to the SQLTransactionBackend destructor
+        which is guaranteed to only be called when the SQLTransaction is also
+        destructing i.e. these objects are no longer needed.
+
+        No new tests.
+
+        * Modules/webdatabase/SQLTransactionBackend.cpp:
+        (WebCore::SQLTransactionBackend::doCleanup):
+
 2013-02-26  Anders Carlsson  <[email protected]>
 
         Implement StorageAreaProxy::getItem and StorageAreaProxy::setItem

Modified: trunk/Source/WebCore/Modules/webdatabase/SQLTransactionBackend.cpp (144134 => 144135)


--- trunk/Source/WebCore/Modules/webdatabase/SQLTransactionBackend.cpp	2013-02-27 02:40:29 UTC (rev 144134)
+++ trunk/Source/WebCore/Modules/webdatabase/SQLTransactionBackend.cpp	2013-02-27 02:51:44 UTC (rev 144135)
@@ -413,10 +413,19 @@
     // There is no harm in letting it finish making the request. It'll set
     // m_requestedState, but we won't execute a transition to that state because
     // we've already shut down the transaction.
+    //
+    // We also can't clear m_currentStatementBackend and m_transactionError.
+    // m_currentStatementBackend may be accessed asynchronously by the
+    // frontend's deliverStatementCallback() state. Similarly,
+    // m_transactionError may be accessed by deliverTransactionErrorCallback().
+    // This occurs if requests for transition to those states have already been
+    // registered with the frontend just prior to a clean up request arriving.
+    //
+    // So instead, let our destructor handle their clean up since this
+    // SQLTransactionBackend is guaranteed to not destruct until the frontend
+    // is also destructing.
 
-    m_currentStatementBackend = 0;
     m_wrapper = 0;
-    m_transactionError = 0;
 }
 
 AbstractSQLStatement* SQLTransactionBackend::currentStatement()
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to