fast/workers/storage/interrupt-database.html sometimes crashes on Debug builds. Example Eror Log from Chromium Mac 10.6 Debug Bot: ERROR: Unable to turn on incremental auto-vacuum (0 not an error) /b/build/slave/webkit-mac-latest-dbg/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../storage/AbstractDatabase.cpp(272) : virtual bool WebCore::AbstractDatabase::performOpenAndVerify(bool, ExceptionCode &, WTF::String &) ERROR: Failed to set maximum size of database to 5211136 bytes /b/build/slave/webkit-mac-latest-dbg/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../platform/sql/SQLiteDatabase.cpp(182) : void WebCore::SQLiteDatabase::setMaximumSize(int64_t) ASSERTION FAILED: m_workerContext->hasOneRef() /b/build/slave/webkit-mac-latest-dbg/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../workers/WorkerThread.cpp(165) : void *WebCore::WorkerThread::workerThread() 1 0x2fb6c427 WebCore::WorkerThread::workerThread() 2 0x2fb6c07c WebCore::WorkerThread::workerThreadStart(void*) 3 0x2d2ba927 WTF::threadEntryPoint(void*) 4 0x964e1259 _pthread_start 5 0x964e10de thread_start [2440:-1341116416:1717979162936:ERROR:process_util_posix.cc(142)] Received signal 11 0 DumpRenderTree 0x2cead04f base::debug::StackTrace::StackTrace() + 63 1 DumpRenderTree 0x2ceacfeb base::debug::StackTrace::StackTrace() + 43 2 DumpRenderTree 0x2d5420f7 base::(anonymous namespace)::StackDumpSignalHandler(int, __siginfo*, __darwin_ucontext*) + 295 3 libSystem.B.dylib 0x9651a05b _sigtramp + 43 4 ??? 0xffffffff 0x0 + 4294967295 5 DumpRenderTree 0x2fb6c07c WebCore::WorkerThread::workerThreadStart(void*) + 44 6 DumpRenderTree 0x2d2ba927 WTF::threadEntryPoint(void*) + 167 7 libSystem.B.dylib 0x964e1259 _pthread_start + 345 8 libSystem.B.dylib 0x964e10de thread_start + 34 ax: bbadbeef, bx: 1b90cd24, cx: 157c6e38, dx: 157c6e38 di: 30d2e481, si: 30d2e455, bp: b0102f28, sp: b0102e20, ss: 23, flags: 10286 ip: 2fb6c431, cs: 1b, ds: 23, es: 23, fs: 23, gs: f
This test really has an issue. It has been flaky on Windows for some time too.
(In reply to comment #1) > This test really has an issue. It has been flaky on Windows for some time too. Let me take that back until I can try to see if marking it as slow helps with the flakiness.
> Let me take that back until I can try to see if marking it as slow helps with the flakiness. I did not help, it looks it sometimes doesn't finish. I marked the test as timing out on windows release in http://trac.webkit.org/changeset/107406.
(In reply to comment #3) > > Let me take that back until I can try to see if marking it as slow helps with the flakiness. > > I did not help, it looks it sometimes doesn't finish. I marked the test as timing out on windows release in http://trac.webkit.org/changeset/107406. On debug builds, it appears to still be crashing. Seems like it needs to be brought to someone familiar with this stuff to fix.
The test can also hang (time out) on debug builds. E.g. see http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6/builds/15093/steps/webkit_tests/logs/stdio 10:11:54.538 14814 fast/workers/storage/interrupt-database.html -> unexpected test timed out
No longer observing this.