See: http://test-results.appspot.com/dashboards/flakiness_dashboard.html#showExpectations=true&tests=fast%2Fworkers%2Fstorage%2Finterrupt-database.html This seems to be happening across all platforms. Here's a Chromium Mac 10.7 (dbg) log: crash log for DumpRenderTree (pid 2446): STDOUT: <empty> STDERR: ERROR: Unable to turn on incremental auto-vacuum (0 not an error) STDERR: ../../third_party/WebKit/Source/WebCore/Modules/webdatabase/DatabaseBackend.cpp(327) : virtual bool WebCore::DatabaseBackend::performOpenAndVerify(bool, WebCore::DatabaseError &, WTF::String &) STDERR: ASSERTION FAILED: m_nextState == SQLTransactionState::Idle STDERR: ../../third_party/WebKit/Source/WebCore/Modules/webdatabase/SQLTransactionStateMachine.h(85) : void WebCore::SQLTransactionStateMachine<WebCore::SQLTransactionBackend>::setStateToRequestedState() [T = WebCore::SQLTransactionBackend] STDERR: 1 0x8b691ff WebCore::SQLTransactionStateMachine<WebCore::SQLTransactionBackend>::setStateToRequestedState() STDERR: 2 0x8b67e1d WebCore::SQLTransactionBackend::performNextStep() STDERR: 3 0x8b4e80f WebCore::DatabaseBackendAsync::DatabaseTransactionTask::doPerformTask() STDERR: 4 0x8b4e03e WebCore::DatabaseTask::performTask() STDERR: 5 0x8b4f762 WebCore::DatabaseThread::databaseThread() STDERR: 6 0x8b4f5a1 WebCore::DatabaseThread::databaseThreadStart(void*)
Thanks for reporting this. I'm looking into it.
Adrienne, can please note which svn rev your failing build is based on? Are you still seeing this with ToT? I can't seem to reproduce it on my end with ToT. Thanks.
Happening in Chromium at ToT still, but it appears to have been happening for quite some time. The most recent is r143352 on a Win7(dbg). It doesn't appear to happen every time. See the flakiness dashboard link in the original description and click on one of the gold squares to see the revision number that ran at.
*** Bug 110337 has been marked as a duplicate of this bug. ***
The dupe has a few recent instances.
During an interruption, the SQLTransactionBackend will request its frontend to transit to state End. It then proceeds to put itself in state End. The frontend SQLTransaction will try to execute the state transition to End, and discovers the database being interrupted (this is our intent when we told it go to End). Instead, it will initiate clean up which also entails requesting that the SQLTransacionBackend transit to state CleanupAndTerminate. This is not a problem because the backend state machine will detect that the database interruption, repeat the cleanup (no harm), and go to state End anyway. That said, that last state transition is from state End to state End, and this makes the assertion unhappy. I'll provide a patch shortly to clean up the the state dispatch mechanism so that this assertion won't find itself in the interruption path where it does not belong. It only makes sense under normal circumstances.
Created attachment 189360 [details] the fix.
Comment on attachment 189360 [details] the fix. r=me
Thanks for there review. Landed in r143489: <http://trac.webkit.org/changeset/143489>.