[chromium] Threaded compositor locks up when switching tabs

• Component: WebCore Misc.
• Status: RESOLVED DUPLICATE

[Iain Merrick]

I'm hitting this a lot with my dev build. To reproduce, launch the browser, then quickly open several tabs from the new tab page with middle-click or ctrl-click. Switch back and forth through the tabs as they're loading.

Usually, several tabs will lock up. Looks like a deadlock in CCThreadProxy::beginFrame:

#0  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1  0x00007ffff24ed678 in WTF::ThreadCondition::wait (this=0x7fffffffcb48, 
    mutex=...)
    at third_party/WebKit/Source/JavaScriptCore/wtf/ThreadingPthreads.cpp:394
#2  0x00007ffff291da9c in WebCore::CCCompletionEvent::wait (
    this=0x7fffffffcb20)
    at third_party/WebKit/Source/WebCore/platform/graphics/chromium/cc/CCCompletionEvent.h:60
#3  0x00007ffff291ba99 in WebCore::CCThreadProxy::beginFrame (
    this=0x7fffef7a5180)
    at third_party/WebKit/Source/WebCore/platform/graphics/chromium/cc/CCThreadProxy.cpp:464
#4  0x00007ffff292166e in WebCore::CCThreadTask0<WebCore::CCThreadProxy>::performTask (this=0x7fffe22828a0)
    at third_party/WebKit/Source/WebCore/platform/graphics/chromium/cc/CCThreadTask.h:55
#5  0x00007ffff291e15b in WebCore::CCScopedThreadProxy::runTaskIfNotShutdown (
    this=0x7fffe221b980, popTask=...)
    at third_party/WebKit/Source/WebCore/platform/graphics/chromium/cc/CCScopedThreadProxy.h:82
#6  0x00007ffff2921a1b in WebCore::CCThreadTask1<WebCore::CCScopedThreadProxy, WTF::PassOwnPtr<WebCore::CCThread::Task>, WTF::PassOwnPtr<WebCore::CCThread::Task> >::performTask (this=0x7fffe226f210)
    at third_party/WebKit/Source/WebCore/platform/graphics/chromium/cc/CCThreadTask.h:84
#7  0x00007ffff4587277 in WebKit::CCThreadTaskAdapter::run (
    this=0x7fffef801c00)
    at third_party/WebKit/Source/WebKit/chromium/src/CCThreadImpl.cpp:72
#8  0x00007ffff37563d3 in base::internal::RunnableAdapter<void (WebKit::WebThread::Task::*)()>::Run (this=0x7fffffffcca0, object=0x7fffef801c00)
    at ./base/bind_internal.h:132
#9  0x00007ffff3756290 in base::internal::InvokeHelper<false, void, base::internal::RunnableAdapter<void (WebKit::WebThread::Task::*)()>, void (WebKit::WebThread::Task*)>::MakeItSo(base::internal::RunnableAdapter<void (WebKit::WebThread::Task::*)()>, WebKit::WebThread::Task*) (runnable=..., a1=0x7fffef801c00)
    at ./base/bind_internal.h:868
#10 0x00007ffff37560ad in base::internal::Invoker<1, base::internal::BindState<base::internal::RunnableAdapter<void (WebKit::WebThread::Task::*)()>, void (WebKit::WebThread::Task*), void (base::internal::OwnedWrapper<WebKit::WebThread::Task>)>, void (WebKit::WebThread::Task*)>::Run(base::internal::BindStateBase*) (
    base=0x7fffe226f1e0) at ./base/bind_internal.h:1170
#11 0x00007ffff0bd2077 in base::Callback<void ()>::Run() const (
    this=0x7fffffffcfc8) at ./base/callback.h:272
#12 0x00007ffff1471aa4 in MessageLoop::RunTask (this=0x7fffffffd8c0, 
    pending_task=...) at base/message_loop.cc:458
#13 0x00007ffff1471bbb in MessageLoop::DeferOrRunPendingTask (
    this=0x7fffffffd8c0, pending_task=...) at base/message_loop.cc:470
#14 0x00007ffff14723dd in MessageLoop::DoWork (this=0x7fffffffd8c0)
    at base/message_loop.cc:660
#15 0x00007ffff147a0b0 in base::MessagePumpDefault::Run (this=0x7fffef7dc4b0, 
    delegate=0x7fffffffd8c0) at base/message_pump_default.cc:28
#16 0x00007ffff147176b in MessageLoop::RunInternal (this=0x7fffffffd8c0)
    at base/message_loop.cc:417
#17 0x00007ffff147161e in MessageLoop::RunHandler (this=0x7fffffffd8c0)
    at base/message_loop.cc:390
#18 0x00007ffff1470f53 in MessageLoop::Run (this=0x7fffffffd8c0)
    at base/message_loop.cc:300
#19 0x00007ffff408f4f2 in RendererMain (parameters=...)
    at content/renderer/renderer_main.cc:241
#20 0x00007ffff14034ea in (anonymous namespace)::RunNamedProcessTypeMain (
    process_type="renderer", main_function_params=..., delegate=0x7fffffffe100)
    at content/app/content_main_runner.cc:282
#21 0x00007ffff1403d60 in (anonymous namespace)::ContentMainRunnerImpl::Run (
    this=0x7fffef7b1de0) at content/app/content_main_runner.cc:511
#22 0x00007ffff1402c75 in content::ContentMain (argc=8, argv=0x7fffffffe268, 
    delegate=0x7fffffffe100) at content/app/content_main.cc:35
#23 0x00007ffff06321ad in ChromeMain (argc=8, argv=0x7fffffffe268)
    at chrome/app/chrome_main.cc:32
#24 0x00007ffff063216c in main (argc=8, argv=0x7fffffffe268)
    at chrome/app/chrome_exe_main_gtk.cc:18

[Iain Merrick]

Flags: --enable-threaded-compositing --force-compositing-mode

[Iain Merrick]

The last call to CCSchedulerStateMachine::updateState() has:

action: ACTION_NONE
m_needsCommit: true
m_commitState: COMMIT_STATE_UPDATING_RESOURCES
m_visible: false

nextAction() must be returning ACTION_NONE because shouldDraw() is false (we're not visible) and m_updateMoreResourcesPending is false. So it finished updating resource, but isn't drawing because we're not visible.

It should draw when we become visible. However, the main thread is blocked on beginFrame(), waiting for the commit to complete. I guess that prevents the main thread from handling setVisible(true)? If so it seems like we need to dispatch setVisible directly to the impl thread.

Alternatively, we could suppress background drawing some other way. I feel like doing it in the scheduler state machine is a source of bugs.

[Nat Duca]

I think this is dup. Feel free to un-dupe if the patch in 80910 doesn't address the problem.

*** This bug has been marked as a duplicate of bug 80910 ***

[Iain Merrick]

Yep, that fixes it!