1292288 - Deadlock when exiting fullscreen

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect, P1)

Description

[Markus Stange [:mstange]]

Steps to reproduce (I've only done this once, not sure if it reproduces 100%, and this is on 10.12):
1. Watch the video on https://ahal.ca/blog/2016/taskcluster-interactive-loaner/ in fullscreen mode.
2. Click the button to exit fullscreen mode.
3. The screen goes black and Firefox hangs.

Main thread:

> __psynch_mutexwait  (in libsystem_kernel.dylib) + 10  [0x7fffb6abacba]
> _pthread_mutex_lock_wait  (in libsystem_pthread.dylib) + 100  [0x7fffb6ba2f8a]
> _pthread_mutex_lock_slow  (in libsystem_pthread.dylib) + 285  [0x7fffb6ba06cd]
> CGLLockContext  (in OpenGL) + 41  [0x7fffa67986bf]
> -[ChildView setFullscreen:]  (in XUL) + 59  [0x10fc8af2b]
> nsChildView::PrepareWindowEffects()  (in XUL) + 369  [0x10fc83771]
> mozilla::layers::ClientLayerManager::EndTransaction(void (*)(mozilla::layers::PaintedLayer*, gfxContext*, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::layers::DrawRegionClip, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, void*), void*, mozilla::layers::LayerManager::EndTransactionFlags)  (in XUL) + 44  [0x10e6f9b6c]
> nsDisplayList::PaintRoot(nsDisplayListBuilder*, nsRenderingContext*, unsigned int)  (in XUL) + 3958  [0x10ff5a916]
> nsLayoutUtils::PaintFrame(nsRenderingContext*, nsIFrame*, nsRegion const&, unsigned int, nsDisplayListBuilderMode, nsLayoutUtils::PaintFrameFlags)  (in XUL) + 5550  [0x10ff8dcfe]
> PresShell::Paint(nsView*, nsRegion const&, unsigned int)  (in XUL) + 1626  [0x10ffb517a]
> nsViewManager::ProcessPendingUpdatesPaint(nsIWidget*)  (in XUL) + 496  [0x10fc41f30]
> nsViewManager::ProcessPendingUpdatesForView(nsView*, bool)  (in XUL) + 368  [0x10fc41b30]
> nsViewManager::ProcessPendingUpdates()  (in XUL) + 195  [0x10fc42983]
> nsViewManager::WillPaintWindow(nsIWidget*)  (in XUL) + 98  [0x10fc42862]
> nsView::WillPaintWindow(nsIWidget*)  (in XUL) + 26  [0x10fc4073a]
> -[ChildView viewWillDraw]  (in XUL) + 521  [0x10fc8ba89]
> [...]
> -[NSWindow makeKeyAndOrderFront:]  (in AppKit) + 111  [0x7fff9f64bbf7]
> nsCocoaWindow::Show(bool)  (in XUL) + 1431  [0x10fcc7b17]
> nsCocoaWindow::HideWindowChrome(bool)  (in XUL) + 614  [0x10fcc8bf6]
> nsBaseWidget::MakeFullScreen(bool, nsIScreen*)  (in XUL) + 36  [0x10fc47174]
> nsCocoaWindow::DoMakeFullScreen(bool, bool)  (in XUL) + 176  [0x10fcc9330]
> FullscreenTransitionTask::Run()  (in XUL) + 303  [0x10e8e37df]

Compositor thread:

> __psynch_mutexwait  (in libsystem_kernel.dylib) + 10  [0x7fffb6abacba]
> _pthread_mutex_lock_wait  (in libsystem_pthread.dylib) + 100  [0x7fffb6ba2f8a]
> PR_Lock  (in libnss3.dylib) + 14  [0x105fc42de]
> nsChildView::MaybeDrawTitlebar(mozilla::layers::GLManager*)  (in XUL) + 31  [0x10fc84cbf]
> nsChildView::DrawWindowOverlay(mozilla::layers::GLManager*, mozilla::gfx::IntRectTyped<mozilla::LayoutDevicePixel>)  (in XUL) + 64  [0x10fc84c30]
> nsChildView::DrawWindowOverlay(mozilla::layers::LayerManagerComposite*, mozilla::gfx::IntRectTyped<mozilla::LayoutDevicePixel>)  (in XUL) + 53  [0x10fc84bb5]
> mozilla::layers::LayerManagerComposite::Render(mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&)  (in XUL) + 3322  [0x10e738a0a]
> mozilla::layers::LayerManagerComposite::UpdateAndRender()  (in XUL) + 717  [0x10e737a5d]
> mozilla::layers::LayerManagerComposite::EndTransaction(mozilla::TimeStamp const&, mozilla::layers::LayerManager::EndTransactionFlags)  (in XUL) + 183  [0x10e7376c7]
> mozilla::layers::CompositorBridgeParent::CompositeToTarget(mozilla::gfx::DrawTarget*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const*)  (in XUL) + 669  [0x10e74a15d]
> mozilla::layers::CompositorVsyncScheduler::Composite(mozilla::TimeStamp)  (in XUL) + 139  [0x10e749a8b]

Comment 1

[Markus Stange [:mstange]]

This was caused by bug 1230641.

Comment 2

[Matt Woodrow (:mattwoodrow)]

Attachment: childview-deadlock

Main thread was taking mEffectsLock and the the GLContext lock. The compositor thread was trying to do the reverse order and we get stuck.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9e70c48a9b7c
Don't hold both the effects lock and the GL lock at the same time in PrepareWindowEffects to avoid deadlock. r=mstange

Comment 4

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/9e70c48a9b7c