Bug 123383 – REGRESSION: Crashes in -[UIDelegate webView:frame:exceededDatabaseQuotaForSecurityOrigin:database:]

• Component: WebCore Misc.
• Status: RESOLVED FIXED

[Alexey Proskuryakov]

http://build.webkit.org/results/Apple%20MountainLion%20Debug%20WK1%20(Tests)/r158075%20(10998)/storage/websql/sql-error-codes-crash-log.txt

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.JavaScriptCore      	0x000000010b18b59a WTFCrash + 42 (Assertions.cpp:342)
1   DumpRenderTree                	0x000000010aa0a142 -[UIDelegate webView:frame:exceededDatabaseQuotaForSecurityOrigin:database:] + 370 (UIDelegate.mm:178)
2   com.apple.WebKit              	0x000000010c312a5d objc_object* wtfObjcMsgSend<objc_object*, WebView*, objc_object*, objc_object*, objc_object*>(objc_object*, objc_selector*, WebView*, objc_object*, objc_object*, objc_object*) + 61 (ObjcRuntimeExtras.h:38)
3   com.apple.WebKit              	0x000000010c30fe18 CallDelegate(WebView*, objc_object*, objc_selector*, objc_object*, objc_object*, objc_object*) + 120 (WebDelegateImplementationCaching.mm:147)
4   com.apple.WebKit              	0x000000010c30fd95 CallUIDelegate(WebView*, objc_selector*, objc_object*, objc_object, objc_object) + 85 (WebDelegateImplementationCaching.mm:421)
5   com.apple.WebKit              	0x000000010c2ff7eb WebChromeClient::exceededDatabaseQuota(WebCore::Frame*, WTF::String const&, WebCore::DatabaseDetails) + 459 (WebChromeClient.mm:646)

Must have regressed in <http://trac.webkit.org/changeset/157874>.

[Alexey Proskuryakov]

<rdar://problem/15325861>

[Mark Lam]

I've never been able to reproduce this assertion failure naturally when running the layout tests.  However, by inspecting the code, I can simulate conditions that can cause the assertion to fail.  Here's how:

When running the test storage/websql/sql-error-codes.html, we would expect [UIDelegate webView:frame:exceededDatabaseQuotaForSecurityOrigin:database:] to be called twice.  The first time is when the test database is being opened.  The second time is when a SQL transaction statement triggers a quota error. 

The first call gets the DatabaseDetails from the ProposedDatabase mechanism.
The second call gets it from the master Databases.db's Databases table. 

1. In a debugger, set a breakpoint after the completion of the 1st call and run till it breaks.
2. Delete all the databases from your database directory.
3. Continue the run.

Note: you'll have to complete the break and deletion of databases very quickly so as to not trigger a timeout of the test.

With that, the second call will fail to get a DatabaseDetails record for the requested database.

As to why we're sometimes seeing this failure in the layout test runs on the bots, my educated guess is that when running multiple tests in parallel, there's a chance that 2 or tests are attempting to write to the master Databases.db at the same time, and 1 of them may fail.  If the one that failed is the one that attempted to write the entry for the storage/websql/sql-error-codes.html's test database (when it was being opened) into Databases.db's Databases table, then the 2nd call to the UIDelegate will fail because it won't find an entry in that table, and the ProposedDatabase mechanism isn't in use then.

I'll look into a fix that will harden the code against such error conditions.

[Mark Lam]

After analyzing the code, we determine that it is appropriate to return a DatabaseDetails with a 0 size if the master Databases.db or the requested database does not exists (or has been deleted).  The issue here is really that the assertion I added to DumpRenderTree is inappropriate, and that the test infrastructure for testing quota expansion is too fragile.

The fix: remove the assertion, and enhance DumpRenderTree and WebKitTestRunner to only check for quota expansion when the appropriate for the test.

Patch coming soon.

[Mark Lam]

Created attachment 215709 [details]
the patch.

[EFL EWS Bot]

Comment on attachment 215709 [details]
the patch.

Attachment 215709 [details] did not pass efl-ews (efl):
Output: http://webkit-queues.appspot.com/results/19478051

[Mark Lam]

Created attachment 215710 [details]
patch 2: fixed efl build breakage.

[Geoffrey Garen]

r=me

[Mark Lam]

Thanks for the review.  Landed in r158447: <http://trac.webkit.org/r158447>.