Bug 77136 – Layout Test fast/workers/storage/interrupt-database.html is a flaky crasher on Debug Chromium Bots

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: Tools / Tests

[Levi Weintraub]

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

[Julien Chaffraix]

This test really has an issue. It has been flaky on Windows for some time too.

[Julien Chaffraix]

(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.

[Julien Chaffraix]

> 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.

[Levi Weintraub]

(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.

[Mikhail Naganov]

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

[Ryosuke Niwa]

No longer observing this.