RESOLVED FIXED 90141
REGRESSION (r121395): fast/workers/worker-context-gc.html failing on GTK Linux 64-bit Debug, Release 
https://bugs.webkit.org/show_bug.cgi?id=90141
Summary REGRESSION (r121395): fast/workers/worker-context-gc.html failing on GTK Linu...
Zan Dobersek
Reported 2012-06-27 23:59:12 PDT
fast/workers/worker-context-gc.html started failing on GTK Linux 64-bit Debug after r121395. http://trac.webkit.org/changeset/121395/ http://build.webkit.org/results/GTK%20Linux%2064-bit%20Debug/r121381%20(34412)/results.html passed http://build.webkit.org/results/GTK%20Linux%2064-bit%20Debug/r121407%20(34422)/results.html failed The test crashes in both release and debug builds: http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40ToT%20-%20webkit.org&revision=121132&tests=fast%2Fworkers%2Fworker-context Crash log for DumpRenderTree (pid 17066): [New LWP 17066] [New LWP 17071] [New LWP 19278] [Thread debugging using libthread_db enabled] Core was generated by `/home/slave/webkitgtk/gtk-linux-64-debug/build/WebKitBuild/Debug/Programs/DumpR'. Program terminated with signal 11, Segmentation fault. #0 0x00007ffebc108e9a in WebCore::Page::group (this=0x0) at ../../Source/WebCore/page/Page.h:166 166 PageGroup& group() { if (!m_group) initGroup(); return *m_group; } Thread 3 (Thread 0x7ffe6235f700 (LWP 19278)): #0 0x00007ffeb8caf63b in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007ffeba085075 in g_cond_wait_until () from /home/slave/webkitgtk/gtk-linux-64-debug/build/WebKitBuild/Dependencies/Root/lib64/libglib-2.0.so.0 #2 0x00007ffeba003d71 in g_async_queue_pop_intern_unlocked () from /home/slave/webkitgtk/gtk-linux-64-debug/build/WebKitBuild/Dependencies/Root/lib64/libglib-2.0.so.0 #3 0x00007ffeba003ff0 in g_async_queue_timeout_pop_unlocked () from /home/slave/webkitgtk/gtk-linux-64-debug/build/WebKitBuild/Dependencies/Root/lib64/libglib-2.0.so.0 #4 0x00007ffeba062fa2 in g_thread_pool_wait_for_new_task () from /home/slave/webkitgtk/gtk-linux-64-debug/build/WebKitBuild/Dependencies/Root/lib64/libglib-2.0.so.0 #5 0x00007ffeba062fdf in g_thread_pool_thread_proxy () from /home/slave/webkitgtk/gtk-linux-64-debug/build/WebKitBuild/Dependencies/Root/lib64/libglib-2.0.so.0 #6 0x00007ffeba062a51 in g_thread_proxy () from /home/slave/webkitgtk/gtk-linux-64-debug/build/WebKitBuild/Dependencies/Root/lib64/libglib-2.0.so.0 #7 0x00007ffeb8caab40 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #8 0x00007ffeb89f536d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #9 0x0000000000000000 in ?? () Thread 2 (Thread 0x7ffe6bba9700 (LWP 17071)): #0 0x00007ffeb8caf63b in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007ffec0c81447 in WTF::ThreadCondition::timedWait (this=0x2132bc8, mutex=..., absoluteTime=1340861987.0129919) at ../../Source/WTF/wtf/ThreadingPthreads.cpp:417 #2 0x00007ffec0a9b62e in JSC::BlockAllocator::waitForRelativeTimeWhileHoldingLock (this=0x2132b80, relative=1) at ../../Source/JavaScriptCore/heap/BlockAllocator.cpp:82 #3 0x00007ffec0a9b66d in JSC::BlockAllocator::waitForRelativeTime (this=0x2132b80, relative=1) at ../../Source/JavaScriptCore/heap/BlockAllocator.cpp:92 #4 0x00007ffec0a9b6bb in JSC::BlockAllocator::blockFreeingThreadMain (this=0x2132b80) at ../../Source/JavaScriptCore/heap/BlockAllocator.cpp:105 #5 0x00007ffec0a9b694 in JSC::BlockAllocator::blockFreeingThreadStartFunc (blockAllocator=0x2132b80) at ../../Source/JavaScriptCore/heap/BlockAllocator.cpp:97 #6 0x00007ffec0c80369 in WTF::threadEntryPoint (contextData=0x1ab9e70) at ../../Source/WTF/wtf/Threading.cpp:69 #7 0x00007ffec0c809fb in WTF::wtfThreadEntryPoint (param=0x2127fe0) at ../../Source/WTF/wtf/ThreadingPthreads.cpp:162 #8 0x00007ffeb8caab40 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #9 0x00007ffeb89f536d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #10 0x0000000000000000 in ?? () Thread 1 (Thread 0x7ffec103e900 (LWP 17066)): #0 0x00007ffebc108e9a in WebCore::Page::group (this=0x0) at ../../Source/WebCore/page/Page.h:166 #1 0x00007ffebcf91a39 in WebCore::WorkerMessagingProxy::startWorkerContext (this=0xaaefde0, scriptURL=..., userAgent="(null)", sourceCode="function gc()\n{\n for (var i = 0; i < 10000; i++) { // > force garbage collection (FF requires about 9K allocations before a collect)\n var s = new String(\"abc\");\n }\n}\n\nonmessage = function"..., startMode=WebCore::DontPauseWorkerContextOnStart) at ../../Source/WebCore/workers/WorkerMessagingProxy.cpp:276 #2 0x00007ffebcf906ee in WebCore::Worker::notifyFinished (this=0xaaefd30) at ../../Source/WebCore/workers/Worker.cpp:152 #3 0x00007ffebcf9931c in WebCore::WorkerScriptLoader::notifyFinished (this=0xac90560) at ../../Source/WebCore/workers/WorkerScriptLoader.cpp:188 #4 0x00007ffebcf99269 in WebCore::WorkerScriptLoader::didFinishLoading (this=0xac90560, identifier=3376) at ../../Source/WebCore/workers/WorkerScriptLoader.cpp:163 #5 0x00007ffebc932e11 in WebCore::DocumentThreadableLoader::didFinishLoading (this=0xac523d0, identifier=3376, finishTime=0) at ../../Source/WebCore/loader/DocumentThreadableLoader.cpp:325 #6 0x00007ffebc932ca9 in WebCore::DocumentThreadableLoader::notifyFinished (this=0xac523d0, resource=0x9afd910) at ../../Source/WebCore/loader/DocumentThreadableLoader.cpp:310 #7 0x00007ffebc90d31c in WebCore::CachedResource::didAddClient (this=0x9afd910, c=0xac523f8) at ../../Source/WebCore/loader/cache/CachedResource.cpp:388 #8 0x00007ffebc90a8df in WebCore::CachedRawResource::didAddClient (this=0x9afd910, c=0xac523f8) at ../../Source/WebCore/loader/cache/CachedRawResource.cpp:87 #9 0x00007ffebc90eed6 in WebCore::CachedResource::CachedResourceCallback::timerFired (this=0xac20d00) at ../../Source/WebCore/loader/cache/CachedResource.cpp:777 #10 0x00007ffebc915daa in WebCore::Timer<WebCore::CachedResource::CachedResourceCallback>::fired (this=0xac20d10) at ../../Source/WebCore/platform/Timer.h:100 #11 0x00007ffebcb8a6b8 in WebCore::ThreadTimers::sharedTimerFiredInternal (this=0x1aa6450) at ../../Source/WebCore/platform/ThreadTimers.cpp:115 #12 0x00007ffebcb8a5ef in WebCore::ThreadTimers::sharedTimerFired () at ../../Source/WebCore/platform/ThreadTimers.cpp:93 #13 0x00007ffebd61eb4a in WebCore::timeout_cb () at ../../Source/WebCore/platform/gtk/SharedTimerGtk.cpp:49 #14 0x00007ffeba038105 in g_timeout_dispatch () from /home/slave/webkitgtk/gtk-linux-64-debug/build/WebKitBuild/Dependencies/Root/lib64/libglib-2.0.so.0 #15 0x00007ffeba036359 in g_main_dispatch () from /home/slave/webkitgtk/gtk-linux-64-debug/build/WebKitBuild/Dependencies/Root/lib64/libglib-2.0.so.0 #16 0x00007ffeba037003 in g_main_context_dispatch () from /home/slave/webkitgtk/gtk-linux-64-debug/build/WebKitBuild/Dependencies/Root/lib64/libglib-2.0.so.0 #17 0x00007ffeba0371ed in g_main_context_iterate () from /home/slave/webkitgtk/gtk-linux-64-debug/build/WebKitBuild/Dependencies/Root/lib64/libglib-2.0.so.0 #18 0x00007ffeba037623 in g_main_loop_run () from /home/slave/webkitgtk/gtk-linux-64-debug/build/WebKitBuild/Dependencies/Root/lib64/libglib-2.0.so.0 #19 0x00007ffeba92c843 in gtk_main () from /home/slave/webkitgtk/gtk-linux-64-debug/build/WebKitBuild/Dependencies/Root/lib64/libgtk-3.so.0 #20 0x000000000045fbd8 in runTest (testPathOrURL=...) at ../../Tools/DumpRenderTree/gtk/DumpRenderTree.cpp:706 #21 0x000000000045f241 in runTestingServerLoop () at ../../Tools/DumpRenderTree/gtk/DumpRenderTree.cpp:491 #22 0x00000000004622a2 in main (argc=2, argv=0x7fffa71a0f48) at ../../Tools/DumpRenderTree/gtk/DumpRenderTree.cpp:1396 STDERR: STDERR: warning: Can't read pathname for load map: Input/output error. STDERR: warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.) STDERR: STDERR: warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.) STDERR: STDERR: <empty> CC-ing author and reviewer of r121395.
Attachments
Add attachment proposed patch, testcase, etc.
David Levin
Comment 1 2012-06-28 00:05:55 PDT
I would roll out the change. btw, I just noticed that this line in trunk/Source/WebCore/workers/WorkerThread.cpp: m_groupSettings->setIndexedDBDatabasePath(settings->indexedDBDatabasePath()); is incorrect. It should be m_groupSettings->setIndexedDBDatabasePath(settings->indexedDBDatabasePath().isolatedCopy()); but I doubt that issue is causing this problem.
David Levin
Comment 2 2012-06-28 00:18:32 PDT
I suppose the questions to ask are: 1. Why use m_workerObject in WorkerMessagingProxy::startWorkerContext when it already has m_scriptExecutionContext? 2. How do you know that every item in the line "m_workerObject->scriptExecutionContext())->page()->group().groupSettings()" is alive by the time that this method is called? I should have noticed this stuff in the original code review.
Adam Barth
Comment 3 2012-06-28 00:21:23 PDT
By the way, we're considering moving the IDB state from PageGroup to just Page to make IDB work more like some of the other storage systems.
Zan Dobersek
Comment 4 2012-06-28 01:37:35 PDT
Rolled out in bug #90143, bug #88338 reopened. Removing the crash expectation shortly.
Note You need to log in before you can comment on or make changes to this bug.