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>.
<rdar://problem/15325861>
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.
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.
Created attachment 215709 [details] the patch.
Comment on attachment 215709 [details] the patch. Attachment 215709 [details] did not pass efl-ews (efl): Output: http://webkit-queues.appspot.com/results/19478051
Created attachment 215710 [details] patch 2: fixed efl build breakage.
r=me
Thanks for the review. Landed in r158447: <http://trac.webkit.org/r158447>.