1782006 - Crash in [@ mozilla::detail::MutexImpl::lock | mozilla::detail::RunnableFunction<T>::Run]

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect, P2)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

12 crashes from 8+ different devices

Crash report: https://crash-stats.mozilla.org/report/index/e05d96ec-291c-4532-9ec3-59d310220728

MOZ_CRASH Reason: MOZ_CRASH(mozilla::detail::MutexImpl::mutexLock: pthread_mutex_lock failed)

Top 10 frames of crashing thread:

0 firefox-bin mozilla::detail::MutexImpl::lock mozglue/misc/Mutex_posix.cpp:118
1 libxul.so mozilla::detail::RunnableFunction<mozilla::widget::WindowSurfaceProvider::EndRemoteDrawingInRegion xpcom/threads/nsThreadUtils.h:531
2 libxul.so mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:851
3 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1205
4 libxul.so mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:85
5 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:355
6 libxul.so nsBaseAppShell::Run widget/nsBaseAppShell.cpp:150
7 libxul.so nsAppStartup::Run toolkit/components/startup/nsAppStartup.cpp:295
8 libxul.so XREMain::XRE_mainRun toolkit/xre/nsAppRunner.cpp:5700
9 libxul.so XREMain::XRE_main toolkit/xre/nsAppRunner.cpp:5894

Comment 1

[Martin Stránský [:stransky] (ni? me)]

Thanks, looks like it comes from this place:
https://searchfox.org/mozilla-central/rev/2bbb0c0a90df20702df8c8011a8996536a83cb75/widget/gtk/WindowSurfaceProvider.cpp#181

Comment 2

[Darkspirit]

Gnome Wayland, Debian Testing, Intel
Happens sometimes when I try to drag a tab. It's not reliably reproducible.

Comment 3

[Gabriele Svelto [:gsvelto] (PTO)]

There's at least another crash with a comment mentioning dragging a tab.

Comment 4

[Gabriele Svelto [:gsvelto] (PTO)]

IIUC it seems like trying to grab this mutex is failing, most likely because the mutex isn't initialized (or has been destroyed?). I suspect there must be a race related to the mProvider object in the GtkCompositorWidget.

Comment 5

[Martin Stránský [:stransky] (ni? me)]

(In reply to Gabriele Svelto [:gsvelto] from comment #4)

IIUC it seems like trying to grab this mutex is failing, most likely because the mutex isn't initialized (or has been destroyed?). I suspect there must be a race related to the mProvider object in the GtkCompositorWidget.

Yes, I think NS_NewRunnableFunction() is called after nsWindow::Destroy() when compositor is already deleted.

Comment 6

[Martin Stránský [:stransky] (ni? me)]

I think widget->IsDestroyed() should do the trick as we hold reference to mWidget.

Comment 7

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1782006 [Wayland] Check if widget is live at WindowSurfaceProvider::EndRemoteDrawingInRegion() r?emilio

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/78a0b6b0e842
[Wayland] Check if widget is live at WindowSurfaceProvider::EndRemoteDrawingInRegion() r=emilio

Comment 9

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/78a0b6b0e842