Closed Bug 2092792 Opened 1 day ago Closed 1 day ago

Crash in [@ mozilla::widget::WaylandBuffer::GetSurface]

Categories

(Core :: Graphics: WebRender, defect)

defect

Tracking

()

RESOLVED FIXED
162 Branch
Tracking Status
firefox-esr153 --- unaffected
firefox160 --- unaffected
firefox161 --- unaffected
firefox162 --- fixed

People

(Reporter: clouseau-bot, Assigned: stransky)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 external file)

Crash report: https://crash-stats.mozilla.org/report/index/1f30353f-c246-4123-b085-be16e0261114

Crash Reason:

SIGSEGV / SEGV_MAPERR at 0x0000000000000000

Top 10 frames:

0  libxul.so  mozilla::layers::NativeLayerWaylandExternal::GetSurface()  gfx/layers/NativeLayerWayland.cpp:1285
1  libxul.so  mozilla::layers::NativeLayerWayland::SetColorProperties(mozilla::widget::Wayland...  gfx/layers/NativeLayerWayland.cpp:1063
2  libxul.so  mozilla::layers::NativeLayerWayland::Map(mozilla::widget::WaylandSurfaceLock&)  gfx/layers/NativeLayerWayland.cpp:1050
3  libxul.so  mozilla::layers::NativeLayerRootWayland::SetLayers(nsTArray<RefPtr<mozilla::laye...  gfx/layers/NativeLayerWayland.cpp:479
4  libxul.so  mozilla::wr::RenderCompositorLayerNative::CompositorEndFrame()  gfx/webrender_bindings/RenderCompositorLayerNative.cpp:267
5  libxul.so  webrender::renderer::Renderer::render_impl  gfx/wr/webrender/src/renderer/mod.rs:2056
6  libxul.so  webrender::renderer::Renderer::render  gfx/wr/webrender/src/renderer/mod.rs:1613
7  libxul.so  wr_renderer_render  gfx/webrender_bindings/src/bindings.rs:665
8  libxul.so  mozilla::wr::RenderThread::UpdateAndRender(mozilla::wr::WrWindowId, mozilla::lay...  gfx/webrender_bindings/RenderThread.cpp:911
9  libxul.so  mozilla::wr::RenderThread::HandleFrameOneDoc(mozilla::wr::WrWindowId, mozilla::w...  gfx/webrender_bindings/RenderThread.cpp:673

There is 1 crash in nightly 162 with buildid 20261113211735.

Crash-stats has no report of this signature on any earlier build, and Socorro's all-time signature index has no entry for it yet — as far as we can tell it is new with this build.

Nimbus recipes that went live shortly before this signature's first report:

  • Experiment smart-window-guest-nightly went live on 2026-11-12 21:07 UTC, 28 hours before the first report. Feature smartWindow shares window with the top of the stack.
    Publication timing and shared terms alone do not establish causation.

Clouseau analysis (automated, 72% 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:

NativeLayerWaylandExternal::GetSurface() dereferences a null mFrontBuffer when NativeLayerRootWayland::SetLayers maps a newly added external layer that has not been committed yet.

  1. c77276e1ea99 moved creation of mFrontBuffer out of AttachExternalImage into CommitFrontBufferToScreenLocked; AttachExternalImage now only stores mFrontBufferSurface.
  2. a241ce958fc9 replaced the null-safe return GetBufferSurface(mTextureHost); with return mFrontBuffer->GetSurface();.
  3. SetLayers calls layer->Map(lock) for IsNew() layers, Map calls SetColorProperties, and that calls GetSurface(), before the layer's first commit has created mFrontBuffer.
  4. The inlined WaylandBuffer::GetSurface() reads mBufferSurface through the null this, faulting at offset 0x48.

The report fits this chain: the fault address is 0x48, the instruction is mov rcx, qword [rcx + 0x48], frame #0 is the line a241ce958fc9 added, and frames #1 to #3 are the SetColorProperties → Map → SetLayers path. SetColorProperties already returns early on a null surface, so callers expect null. The 0x48 offset was worked out by hand from the pinned WaylandBuffer.h, not from the layout tool. That Map runs before the first commit is read from SetLayers, not seen in the dump. DiscardBackbuffersLocked also nulls mFrontBuffer, so a re-map after a discard is a second possible path.

This crash is from build 20261113211735, which contains both c77276e1ea99 and a241ce958fc9 (both landed 2026-11-13). Blame on the crashing line 1285 names a241ce958fc9. The signature has no recorded first appearance before this build. Hardware-error share is 0% and the CPU is AMD, not an affected Raptor Lake part. The related signature NativeLayerWayland::Map predates this change (first seen 2025-12) and is a separate crash, not a control for this one.

Suspected regressor: a241ce958fc9 (gh) (bug 2084900) by :stransky.

Impact

The parent process crashes, so the whole browser closes.

Possible fixes

  • Make NativeLayerWaylandExternal::GetSurface() return mFrontBufferSurface, which AttachExternalImage sets before Map, instead of going through mFrontBuffer.
  • Alternatively, null-check it: return mFrontBuffer ? RefPtr<BufferSurface>(mFrontBuffer->GetSurface()) : nullptr;, so SetColorProperties keeps its early return.
  • Possibly re-apply color properties at the first commit, so a layer mapped before its first buffer still gets them.

How to confirm

On a Wayland session with the native compositor enabled, play a video that is promoted to an external layer (for example a DMABuf/VAAPI video entering fullscreen or a new external layer appearing). With current nightly, Map should crash in GetSurface() on the first frame of the new layer. MOZ_LOG=WidgetWayland:5 should show Map new child layer with no AttachLocked before it.

Code references:

What the automated skeptic pass checked

In its own words (a pass means the check succeeded, which is not always support for the conclusion):

  • pass hunk0 — The parent rev 3b110bfaaa16 (lines 1285-1300) has the null-safe GetBufferSurface(mTextureHost). The crash build fb0bcf4048ae line 1285 is return mFrontBuffer->GetSurface();, which matches frame #0.
  • pass hunk1 — Creation of mFrontBuffer moved from AttachExternalImage to CommitFrontBufferToScreenLocked, and HasFrontBuffer now tests mFrontBufferSurface. The change is in the crashing build.
  • pass edge0 — Pinned lines 475-479 show SetLayers calling Map for IsNew() layers; Map calls SetColorProperties (1050), which calls GetSurface() (1063). That Map runs before the first commit is inferred from the IsNew() gate, not observed in the dump.
  • pass layout — Derived by hand from the pinned widget/gtk/WaylandBuffer.h (lines 27-93): mBufferSurface is at 0x48, which matches the fault address and mov rcx, qword [rcx + 0x48]. The searchfox field_layout tool returned no rows for this class.
  • pass mechanism — SetColorProperties already handles a null surface (if (!surface) { return; }, line 1064), so the intended contract is null-safe and the new unconditional dereference breaks it.

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

:stransky, can you have a look please?

Filed automatically by Clouseau with an LLM, from a submitted crash report: not an independent Mozilla discovery

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.

This is not an independent Mozilla discovery: the crash is known here only because somebody submitted the crash report linked at the top. If this duplicates an existing report, please resolve THIS bug as the duplicate and leave the credit with the earlier reporter.

Flags: needinfo?(stransky)

Set release status flags based on info from the regressing bug 2084900

Assignee: nobody → stransky
Status: NEW → ASSIGNED
Pushed by stransky@redhat.com: https://github.com/mozilla-firefox/firefox/commit/7b75579564ed https://hg.mozilla.org/integration/autoland/rev/58cfd1f6bcfc [Wayland] Use mFrontBufferSurface so surface setup instead of mFrontBuffer which is set on commit only r=emilio
Pushed by csabou@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/c72617c01649 https://hg.mozilla.org/mozilla-central/rev/ba1611bc9aa6 [Wayland] Use mFrontBufferSurface so surface setup instead of mFrontBuffer which is set on commit only r=emilio
Status: ASSIGNED → RESOLVED
Closed: 1 day ago
Resolution: --- → FIXED
Target Milestone: --- → 162 Branch
Flags: needinfo?(stransky)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: