RESOLVED FIXED86911
IndexedDB: "ASSERTION FAILED: !m_requestFinished" hit in IDBRequest::dispatchEvent
https://bugs.webkit.org/show_bug.cgi?id=86911
Summary IndexedDB: "ASSERTION FAILED: !m_requestFinished" hit in IDBRequest::dispatch...
Joshua Bell
Reported 2012-05-18 15:41:34 PDT
Created attachment 142799 [details] Repro case Seen in DumpRenderTree with attached LayoutTest (which could be dropped into storage/indexeddb for dependencies): crash log for DumpRenderTree (pid 8867): STDERR: ASSERTION FAILED: !m_requestFinished STDERR: ../../third_party/WebKit/Source/WebCore/Modules/indexeddb/IDBRequest.cpp(342) : virtual bool WebCore::IDBRequest::dispatchEvent(WTF::PassRefPtr<WebCore::Event>) What's probably happening is the transaction is completing, and IDBTransaction::onComplete() calls IDBTransaction::closeOpenCursors() calls IDBCursor::close() calls IDBRequest::finishCursor() which sets m_cursorFinished, which allows m_requestFinished to be set. This may be happening too early.
Attachments
Repro case (702 bytes, text/html)
2012-05-18 15:41 PDT, Joshua Bell
no flags
Real repro case (665 bytes, text/html)
2012-05-18 15:47 PDT, Joshua Bell
no flags
Patch (24.09 KB, patch)
2012-07-19 15:21 PDT, Joshua Bell
no flags
Patch (24.10 KB, patch)
2012-07-20 14:44 PDT, Joshua Bell
no flags
Joshua Bell
Comment 1 2012-05-18 15:47:24 PDT
Created attachment 142804 [details] Real repro case
Joshua Bell
Comment 2 2012-05-18 15:48:16 PDT
Comment on attachment 142799 [details] Repro case Whoops. First repro had been reduced too far and I was testing the wrong file. Look at the second one that has noSuchFunction
Joshua Bell
Comment 3 2012-05-21 11:42:16 PDT
(In reply to comment #2) > (From update of attachment 142799 [details]) > Whoops. First repro had been reduced too far and I was testing the wrong file. Look at the second one that has noSuchFunction ... and I admit I now have no idea what's going on. Changing the ordering of lines in the minimal repro - e.g. when the non-existent handler is assigned - makes the issue go away, which means my previous theory is incorrect.
Joshua Bell
Comment 4 2012-06-14 16:22:45 PDT
Ah, here's the key bit: request = store.openCursor(); request.onsuccess = function () { event.target.result.continue(); throw "foo"; }; If an exception is thrown in the event handler after the continue() is called the ASSERT is hit.
Joshua Bell
Comment 5 2012-06-14 16:43:57 PDT
The uncaught exception is causing the transaction to be aborted, which closes the cursor which sets m_requestFinished on the IDBRequest between an event being enqueued and it being dispatched.
Joshua Bell
Comment 6 2012-06-14 17:08:31 PDT
(In reply to comment #5) > The uncaught exception is causing the transaction to be aborted, which closes the cursor which sets m_requestFinished on the IDBRequest between an event being enqueued and it being dispatched. Scratch that, not quite correct. Here's what's going on: * success event fired at the cursor request * success event dispatched by the cursor request * script calls continue(), which queues an task in the transaction * script raises an exception, which aborts the transaction * transaction aborting closes the cursor * transaction aborting aborts the queued task, which fires an error event at the cursor request * cursor request attempt to dispatch the error event, and ASSERTs
Joshua Bell
Comment 7 2012-06-14 17:18:34 PDT
Seems like we need to untangle things slightly - either the cursor shouldn't "finish" the request while there are outstanding events, or we should allow the error event to be dispatched even if the cursor is closed. Given that dispatch can be arbitrarily delayed, it seems like the latter is more tractable. (The timing difference between event queuing and dispatching is tricksy.)
Joshua Bell
Comment 8 2012-07-09 13:40:05 PDT
Note that this still repros after the untangling in 90412 (which makes sense because that patch should only impact multiprocess ports, whereas this repros DRT), but any fix here should wait until that lands since it touches related code.
Joshua Bell
Comment 9 2012-07-19 15:21:09 PDT
Joshua Bell
Comment 10 2012-07-19 15:24:25 PDT
Counting only "interesting" LOC, IDBRequest.cpp is now 20% ASSERTs! dgrogan@, alecflett@ - please take a look.
David Grogan
Comment 11 2012-07-20 14:20:24 PDT
Comment on attachment 153361 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=153361&action=review LGTM > Source/WebCore/Modules/indexeddb/IDBRequest.h:76 > bool resetReadyState(IDBTransaction*); Can this line be deleted?
Joshua Bell
Comment 12 2012-07-20 14:44:43 PDT
Joshua Bell
Comment 13 2012-07-20 14:45:36 PDT
(In reply to comment #11) > > Source/WebCore/Modules/indexeddb/IDBRequest.h:76 > > bool resetReadyState(IDBTransaction*); > > Can this line be deleted? Good catch - deleted! tony@ - r?
WebKit Review Bot
Comment 14 2012-07-20 16:51:41 PDT
Comment on attachment 153605 [details] Patch Clearing flags on attachment: 153605 Committed r123275: <http://trac.webkit.org/changeset/123275>
WebKit Review Bot
Comment 15 2012-07-20 16:51:45 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.