2064274 - [Wayland] Crash in [@ mozilla::detail::MutexImpl::mutexLock]

Status: NEW

(Core :: Widget: Gtk, defect)

Description

[Calixte Denizet (:calixte)]

Crash report: https://crash-stats.mozilla.org/report/index/a56da0ba-560e-4a5e-acdc-ef1340260818

MOZ_CRASH Reason:

(kde) wl_fixes#67: error 0: the given registry did not announce global 66
 Proxy: WP:E WP:CA WP:CPCA

Top 10 frames:

0  libxul.so  mozilla::widget::WlLogHandler(char const*, __va_list_tag*)  widget/gtk/nsWaylandDisplay.cpp:1269
1  libwayland-client.so.0
2  libwayland-client.so.0
3  libffi.so.7
4  libEGL_mesa.so.0
5  libwayland-client.so.0
6  libffi.so.7
7  libffi.so.7
8  libffi.so.7
9  libwayland-client.so.0

There is 1 crash in nightly 156 with buildid 20260816083833.

Clouseau analysis (automated, 97% worth investigating — a calibrated estimate that this is worth someone's time, not that the changeset below caused it). The mechanism below fits the evidence but is not proven end-to-end:

The crash is a deliberate MOZ_CRASH in mozilla::widget::WlLogHandler's unmatched-log-pattern fallback, triggered when KDE/KWin rejects Firefox's wl_fixes_ack_global_remove() with WL_FIXES_ERROR_INVALID_ACK_REMOVE (error 0, matching the crash string byte-for-byte). Firefox only sends that ack when wl_fixes is negotiated at protocol version ≥2; bug 2044559 (1ca578862821) had forced version 1 specifically to prevent this, and bug 2054415 (7630cafc691f, landed 2026-07-13, well inside this build's window) reverted that pin to a version-2-capable MIN(version, libraryVersion) bind, reopening the ack_global_remove path that KDE/KWin apparently mishandles.

The crash build (20260816083833) postdates 7630cafc691f (2026-07-13) with no intervening changeset re-adding compositor-specific wl_fixes version guarding, so the reopened v2/ack_global_remove code path is present exactly as landed at the time of this crash.

Starting point — NOT a suspected cause: 7630cafc691f (gh) (bug 2054415) by Vlad Zahorodnii.

This changeset did not land in this build's pushlog window, so there is no evidence here that the crash is a recent regression from it; it is named only as the closest thing found on the crash path. If you know where this actually comes from, that correction is the most useful thing you could leave on this bug.

Code references:

• global_registry_remover
• widget/gtk/nsWaylandDisplay.cpp:913
• global_registry_handler

What the automated skeptic pass checked (its own words — a pass means the check succeeded, which is not always support for the conclusion):

• unverifiable authorship-intent — Cannot confirm from commit message/comment alone whether bug 2054415's author was aware the v2 revert would resurrect the KDE ack-remove rejection (its stated purpose was a different OOB-read bug); doesn't change the mechanism, only tempers 'intentional vs. overlooked' framing.
• pass mechanism-wlloghandler-fallback — WlLogHandler's unmatched-pattern MOZ_CRASH_UNSAFE_PRINTF fallback format (%s) %s Proxy: %s matches the crash string exactly.
• pass error-constant-match — WL_FIXES_ERROR_INVALID_ACK_REMOVE==0 confirms 'error 0' is specifically the ack_global_remove rejection, a deterministic corroborator.
• pass hunk1-1ca578862821 — Diff confirmed: forces wl_fixes bind to version 1, which structurally prevents ack_global_remove (SINCE_VERSION=2).
• pass hunk2-7630cafc691f — Diff confirmed: reverts the v1 force back to a v2-capable MIN(version, libraryVersion) bind, reopening the ack_global_remove path.
• pass window-no-later-guard — file_history for nsWaylandDisplay.cpp between 2026-07-13 and the 2026-08-16 build shows no subsequent commit re-adds KDE/KWin-specific guarding of wl_fixes version.

Filed as a new bug rather than a comment on bug 1695119, bug 1777373 — which are open on this signature, but they were filed before the changeset above landed, so they cannot be about this regression. Please duplicate if that is wrong.

:zzag, can you have a look please?

Filed automatically by Clouseau, which analyses nightly crashes with an LLM. Nothing above was written or checked by a human. Please close it as INVALID if it is wrong — that is useful feedback, not a nuisance.

Comment 1

[Vlad Zahorodnii [:zzag]]

It's a compositor side issue. We asked distros to backport a patch for kwin to reduce the chances of apps getting disconnected. https://mail.kde.org/pipermail/distributions/2026-August/001725.html