Bug 110247

Summary: fast/workers/storage/interrupt-database.html asserts flakily
Product: WebKit Reporter: Adrienne Walker <enne>
Component: WebCore Misc.Assignee: Mark Lam <mark.lam>
Severity: Normal CC: andersca, ap, beidson, enne, ggaren, koivisto, mark.lam, michaeln, sam
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Description Flags
the fix. koivisto: review+

Description Adrienne Walker 2013-02-19 11:59:06 PST
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*)
Comment 1 Mark Lam 2013-02-19 12:29:55 PST
Thanks for reporting this.  I'm looking into it.
Comment 2 Mark Lam 2013-02-19 16:43:58 PST
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.
Comment 3 Adrienne Walker 2013-02-19 16:53:31 PST
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.
Comment 4 Antti Koivisto 2013-02-20 06:27:42 PST
*** Bug 110337 has been marked as a duplicate of this bug. ***
Comment 5 Antti Koivisto 2013-02-20 06:28:45 PST
The dupe has a few recent instances.
Comment 6 Mark Lam 2013-02-20 10:59:32 PST
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.
Comment 7 Mark Lam 2013-02-20 13:02:02 PST
Created attachment 189360 [details]
the fix.
Comment 8 Antti Koivisto 2013-02-20 13:08:09 PST
Comment on attachment 189360 [details]
the fix.

Comment 9 Mark Lam 2013-02-20 13:12:48 PST
Thanks for there review.  Landed in r143489: <http://trac.webkit.org/changeset/143489>.