NativeLayerRootWayland: Crash in [@ mozilla::detail::MutexImpl::lock | MozContainerSurfaceLock::MozContainerSurfaceLock]
Categories
(Core :: Widget: Gtk, defect, P5)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr91 | --- | unaffected |
| firefox-esr102 | --- | unaffected |
| firefox104 | --- | unaffected |
| firefox105 | --- | disabled |
| firefox106 | --- | disabled |
| firefox107 | --- | disabled |
People
(Reporter: mccr8, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: crash, regression)
Crash Data
Attachments
(1 file)
|
(deleted),
text/plain
|
Details |
Crash report: https://crash-stats.mozilla.org/report/index/e143420a-6426-416f-8ecc-ee1af0220818
Reason: SIGSEGV / SEGV_MAPERR
Top 10 frames of crashing thread:
0 libc.so.6 __GI___pthread_mutex_lock /usr/src/debug/glibc-2.35-15.fc36.x86_64/nptl/pthread_mutex_lock.c:80
1 firefox-bin mozilla::detail::MutexImpl::lock mozglue/misc/Mutex_posix.cpp:118
2 libxul.so MozContainerSurfaceLock::MozContainerSurfaceLock widget/gtk/MozContainerWayland.cpp:109
3 libxul.so mozilla::layers::NativeLayerRootWayland::UpdateLayersOnMainThread gfx/layers/NativeLayerWayland.cpp:295
4 libxul.so mozilla::detail::RunnableMethodImpl<mozilla::layers::NativeLayerRootWayland*, void xpcom/threads/nsThreadUtils.h:1200
5 libxul.so mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:851
6 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1205
7 libxul.so mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:85
8 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:356
9 libxul.so nsBaseAppShell::Run widget/nsBaseAppShell.cpp:150
This looks like some kind of Wayland-related null deref.
|
Reporter | |
Comment 1•2 years ago
|
||
This is the set of patches in the first build it showed up in, 20220817091029. Bug 1785072 is in that range, but I don't know if it could have caused this issue.
|
|
Reporter | |
Updated•2 years ago
|
|
||
Comment 2•2 years ago
|
||
I've hit this bug a few times, it happens whenever an extension pop over is closed by clicking on the open tab or clicking on the extension icon again. It doesn't happen most of the time if the pop up is closed by clicking on a new tab however, or if the pop up is opened on a new tab. It also doesn't happen with built-in menus, such as downloads or the Firefox accounts pop up, only extensions. I'm running Firefox 105.0a1 build 20220822095220 on Sway 1.7 with an Intel , on Arch Linux fully updated as of this comment
|
||
Comment 3•2 years ago
|
||
It's because you have enabled NativeLayerRootWayland - it's supposed to be disabled. Robert, may mContainer be already released internally, i.e. this is called after after nsWindow::Destroy() ?
|
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
|
||
Comment 4•2 years ago
|
||
(In reply to Martin Stránský [:stransky] (ni? me) from comment #3)
It's because you have enabled NativeLayerRootWayland - it's supposed to be disabled. Robert, may mContainer be already released internally, i.e. this is called after after nsWindow::Destroy() ?
This may well be - will look at it. @Robert Holt: for the time being disabling gfx.webrender.compositor.force-enabled is probably the best idea. The compositor-integration backend will not become the default in it's current form.
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
||
Comment 7•2 years ago
|
||
A couple more signatures from experimental/testing Debian builds.
|
||
Comment 8•2 years ago
|
||
Since the crash volume is low (less than 15 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.
For more information, please visit auto_nag documentation.
|
|
||
Comment 9•1 year ago
|
||
Adjusting the signature to anticipate the changes in bug 1816846.
Description
•