Closed Bug 1425878 Opened 6 years ago Closed 6 years ago

Shutdown crash with UnobserveVsync

Categories

(Core :: Graphics: WebRender, defect, P3)

Other Branch
defect

Tracking

()

RESOLVED FIXED
mozilla59
Tracking Status
firefox59 --- fixed

People

(Reporter: kats, Assigned: kats)

References

Details

(Whiteboard: [gfx-noted][triage])

Attachments

(1 file)

https://treeherder.mozilla.org/logviewer.html#?job_id=152132201&repo=try&lineNumber=15368

I've seen this same crash intermittently in various try pushes. Stack is this:

 0  firefox!mozilla::detail::MutexImpl::lock [Mutex_posix.cpp:2002ac2eb9b6 : 74 + 0x24]
 1  libxul.so!mozilla::OffTheBooksMutex::Lock [BlockingResourceBase.cpp:2002ac2eb9b6 : 385 + 0x8]
 2  libxul.so!mozilla::CompositorVsyncDispatcher::SetCompositorVsyncObserver [VsyncDispatcher.cpp:2002ac2eb9b6 : 69 + 0xb]
 3  libxul.so!mozilla::widget::InProcessX11CompositorWidget::ObserveVsync [InProcessX11CompositorWidget.cpp:2002ac2eb9b6 : 41 + 0x14]
 4  libxul.so!mozilla::layers::CompositorVsyncScheduler::UnobserveVsync [CompositorVsyncScheduler.cpp:2002ac2eb9b6 : 336 + 0xf]
 5  libxul.so!mozilla::layers::CompositorVsyncScheduler::Destroy [CompositorVsyncScheduler.cpp:2002ac2eb9b6 : 114 + 0x8]
 6  libxul.so!mozilla::layers::WebRenderBridgeParent::ClearResources [WebRenderBridgeParent.cpp:2002ac2eb9b6 : 1415 + 0x14]
 7  libxul.so!mozilla::layers::WebRenderBridgeParent::HandleShutdown [WebRenderBridgeParent.cpp:2002ac2eb9b6 : 251 + 0x5]
 8  libxul.so!mozilla::layers::WebRenderBridgeParent::RecvShutdownSync [WebRenderBridgeParent.cpp:2002ac2eb9b6 : 245 + 0x5]
 9  libxul.so!mozilla::layers::PWebRenderBridgeParent::OnMessageReceived [PWebRenderBridgeParent.cpp: : 871 + 0xc]
10  libxul.so!mozilla::layers::PCompositorManagerParent::OnMessageReceived [PCompositorManagerParent.cpp: : 118 + 0xc]
11  libxul.so!mozilla::ipc::MessageChannel::DispatchAsyncMessage [MessageChannel.cpp:2002ac2eb9b6 : 2110 + 0x6]
12  libxul.so!mozilla::ipc::MessageChannel::DispatchMessage [MessageChannel.cpp:2002ac2eb9b6 : 2040 + 0xb]
13  libxul.so!mozilla::ipc::MessageChannel::RunMessage [MessageChannel.cpp:2002ac2eb9b6 : 1886 + 0xb]
14  libxul.so!mozilla::ipc::MessageChannel::MessageTask::Run [MessageChannel.cpp:2002ac2eb9b6 : 1919 + 0xc]
15  libxul.so!MessageLoop::RunTask [message_loop.cc:2002ac2eb9b6 : 452 + 0x6]
16  libxul.so!MessageLoop::DeferOrRunPendingTask [message_loop.cc:2002ac2eb9b6 : 460 + 0x17]
17  libxul.so!MessageLoop::DoWork [message_loop.cc:2002ac2eb9b6 : 535 + 0x5]
18  libxul.so!base::MessagePumpDefault::Run [message_pump_default.cc:2002ac2eb9b6 : 36 + 0xa]
19  libxul.so!MessageLoop::RunInternal [message_loop.cc:2002ac2eb9b6 : 326 + 0x17]
20  libxul.so!MessageLoop::Run [message_loop.cc:2002ac2eb9b6 : 319 + 0x8]
21  libxul.so!base::Thread::ThreadMain [thread.cc:2002ac2eb9b6 : 181 + 0x8]
Also important is this thread, which I believe is racing with the one above:

 1  libxul.so!mozilla::CondVar::Wait [BlockingResourceBase.cpp:2002ac2eb9b6 : 604 + 0x9]
 2  libxul.so!mozilla::ipc::MessageChannel::WaitForSyncNotify [Monitor.h:2002ac2eb9b6 : 40 + 0xc]
 3  libxul.so!mozilla::ipc::MessageChannel::Send [MessageChannel.cpp:2002ac2eb9b6 : 1472 + 0xe]
 4  libxul.so!mozilla::layers::PCompositorBridgeChild::SendWillClose [PCompositorBridgeChild.cpp: : 386 + 0x1a]
 5  libxul.so!mozilla::layers::CompositorBridgeChild::Destroy [CompositorBridgeChild.cpp:2002ac2eb9b6 : 196 + 0x8]
 6  libxul.so!mozilla::layers::InProcessCompositorSession::Shutdown [InProcessCompositorSession.cpp:2002ac2eb9b6 : 101 + 0xd]
 7  libxul.so!nsBaseWidget::DestroyCompositor [nsBaseWidget.cpp:2002ac2eb9b6 : 292 + 0x11]
 8  libxul.so!nsWindow::Destroy [nsWindow.cpp:2002ac2eb9b6 : 728 + 0xc]
 9  libxul.so!nsXULWindow::Destroy [nsXULWindow.cpp:2002ac2eb9b6 : 512 + 0x11]
10  libxul.so!nsWebShellWindow::Destroy [nsWebShellWindow.cpp:2002ac2eb9b6 : 783 + 0x8]
11  libxul.so!nsGlobalWindowOuter::ReallyCloseWindow [nsGlobalWindowOuter.cpp:2002ac2eb9b6 : 6126 + 0x11]
12  libxul.so!nsCloseEvent::Run [nsGlobalWindowOuter.cpp:2002ac2eb9b6 : 5897 + 0xd]
13  libxul.so!nsThread::ProcessNextEvent [nsThread.cpp:2002ac2eb9b6 : 1039 + 0x15]
15  libxul.so!mozilla::ipc::MessagePump::Run [MessagePump.cpp:2002ac2eb9b6 : 97 + 0xa]
16  libxul.so!MessageLoop::RunInternal [message_loop.cc:2002ac2eb9b6 : 326 + 0x17]
17  libxul.so!MessageLoop::Run [message_loop.cc:2002ac2eb9b6 : 319 + 0x8]
18  libxul.so!nsBaseAppShell::Run [nsBaseAppShell.cpp:2002ac2eb9b6 : 157 + 0xd]
19  libxul.so!nsAppStartup::Run [nsAppStartup.cpp:2002ac2eb9b6 : 288 + 0xe]
20  libxul.so!XREMain::XRE_mainRun [nsAppRunner.cpp:2002ac2eb9b6 : 4709 + 0x15]
21  libxul.so!XREMain::XRE_main [nsAppRunner.cpp:2002ac2eb9b6 : 4871 + 0x8]

This thread is in nsBaseWidget::DestroyCompositor, having gotten past the nulling of mCompositorVsyncDispatcher, at [1]. Meanwhile the other thread gets the same pointer as a raw pointer via [2], wraps it in a RefPtr and then tries to use it [3]. It's possible that the object is freed between returning the raw pointer and the wrapping in a RefPtr. We should return an already_AddRefed or something instead of a raw pointer.

[1] https://searchfox.org/mozilla-central/rev/b1e0ae2573e88391a7ed92407568be77994c9317/widget/nsBaseWidget.cpp#267
[2] https://searchfox.org/mozilla-central/rev/b1e0ae2573e88391a7ed92407568be77994c9317/widget/nsBaseWidget.cpp#1261
[3] https://searchfox.org/mozilla-central/rev/b1e0ae2573e88391a7ed92407568be77994c9317/widget/gtk/InProcessX11CompositorWidget.cpp#41
Assignee: nobody → bugmail
Comment on attachment 8937511 [details]
Bug 1425878 - Don't expose raw pointers to refcounted vsync dispatcher object.

https://reviewboard.mozilla.org/r/208194/#review214010

nice!
Attachment #8937511 - Flags: review?(sotaro.ikeda.g) → review+
Pushed by kgupta@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4309d6abe27f
Don't expose raw pointers to refcounted vsync dispatcher object. r=sotaro
https://hg.mozilla.org/mozilla-central/rev/4309d6abe27f
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: