JavaScriptCore:
authorbeidson@apple.com <beidson@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 5 Mar 2008 22:26:34 +0000 (22:26 +0000)
committerbeidson@apple.com <beidson@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 5 Mar 2008 22:26:34 +0000 (22:26 +0000)
commit731d7d3aa85b4a64a696297104da1562a461c364
treed5ad2f6a279bad468ca3bc5d9e38125e238669d8
parentf690539c099992b377711f8b79ce33d030098e3f
JavaScriptCore:

        Reviewed by Alexey and Mark Rowe

        Fix for <rdar://problem/5778247> - Reproducible crash on storage/execute-sql-args.html

        DatabaseThread::unscheduleDatabaseTasks() manually filters through a MessageQueue,
        removing particular items for Databases that were shutting down.

        This filtering operation is not atomic, and therefore causes a race condition with the
        MessageQueue waking up and reading from the message queue.

        The end result was an attempt to dereference a null DatabaseTask.  Timing-wise, this never
        seemed to happen in a debug build, otherwise an assertion would've caught it.  Replacing that
        assertion with a crash in a release build is what revealed this bug.

        * wtf/MessageQueue.h:
        (WTF::::waitForMessage): Tweak the waiting logic to check the queue's empty state then go back
          to sleep if the queue was empty - checking m_killed each time it wakes up.

WebCore:

        Reviewed by Alexey and Mark Rowe

        Fix for <rdar://problem/5778247> - Reproducible crash on storage/execute-sql-args.html

        DatabaseThread::unscheduleDatabaseTasks() manually filters through a MessageQueue,
        removing particular items for Databases that were shutting down.

        This filtering operation is not atomic, and therefore causes a race condition with the
        database thread waking up and reading from the message queue.

        The end result was an attempt to dereference a null DatabaseTask.  Timing-wise, this never
        seemed to happen in a debug build, otherwise an assertion would've caught it.  Replacing that
        assertion with a crash in a release build is what revealed this bug.

        The fix for the above symptom was entirely in WTF::MessageQueue in JSCore.  With this fix in
        place, another crash popped up in the layout tests that was related to dereferencing a
        deallocated object - simply because SQLTransaction had a raw pointer to it's Database object
        when it needed to be a ref pointer.

        * storage/SQLTransaction.cpp:
        (WebCore::SQLTransaction::runCurrentStatement):
        * storage/SQLTransaction.h: Change m_database to be a RefPtr
        (WebCore::SQLTransaction::database):

LayoutTests:

        Reviewed by Alexey + Mark Rowe

        Fix for <rdar://problem/5778247> - Reproducible crash on storage/execute-sql-args.html

        This test takes its best shot at handling two databases on a single database thread at once,
        then having one of those databases go away completely (garbage collection and everything)

        * storage/multiple-databases-garbage-collection-expected.txt: Added.
        * storage/multiple-databases-garbage-collection.html: Added.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@30811 268f45cc-cd09-0410-ab3c-d52691b4dbfc
JavaScriptCore/ChangeLog
JavaScriptCore/wtf/MessageQueue.h
LayoutTests/ChangeLog
LayoutTests/storage/multiple-databases-garbage-collection-expected.txt [new file with mode: 0644]
LayoutTests/storage/multiple-databases-garbage-collection.html [new file with mode: 0644]
WebCore/ChangeLog
WebCore/storage/SQLTransaction.cpp
WebCore/storage/SQLTransaction.h