Crash in [@ mozilla::widget::WaylandBuffer::GetSurface]
Categories
(Core :: Graphics: WebRender, defect)
Tracking
()
| 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-nightlywent live on 2026-11-12 21:07 UTC, 28 hours before the first report. FeaturesmartWindowshareswindowwith 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.
c77276e1ea99moved creation ofmFrontBufferout ofAttachExternalImageintoCommitFrontBufferToScreenLocked;AttachExternalImagenow only storesmFrontBufferSurface.a241ce958fc9replaced the null-safereturn GetBufferSurface(mTextureHost);withreturn mFrontBuffer->GetSurface();.SetLayerscallslayer->Map(lock)forIsNew()layers,MapcallsSetColorProperties, and that callsGetSurface(), before the layer's first commit has createdmFrontBuffer.- The inlined
WaylandBuffer::GetSurface()readsmBufferSurfacethrough the nullthis, 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()returnmFrontBufferSurface, whichAttachExternalImagesets beforeMap, instead of going throughmFrontBuffer. - Alternatively, null-check it:
return mFrontBuffer ? RefPtr<BufferSurface>(mFrontBuffer->GetSurface()) : nullptr;, soSetColorPropertieskeeps 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:
- gfx/layers/NativeLayerWayland.cpp:1285
- gfx/layers/NativeLayerWayland.cpp:1300
- gfx/layers/NativeLayerWayland.cpp:1499
- mozilla::layers::NativeLayerWayland::mFrontBuffer
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-safeGetBufferSurface(mTextureHost). The crash buildfb0bcf4048aeline 1285 isreturn mFrontBuffer->GetSurface();, which matches frame #0. - pass hunk1 — Creation of
mFrontBuffermoved fromAttachExternalImagetoCommitFrontBufferToScreenLocked, andHasFrontBuffernow testsmFrontBufferSurface. The change is in the crashing build. - pass edge0 — Pinned lines 475-479 show
SetLayerscallingMapforIsNew()layers;MapcallsSetColorProperties(1050), which callsGetSurface()(1063). ThatMapruns before the first commit is inferred from theIsNew()gate, not observed in the dump. - pass layout — Derived by hand from the pinned
widget/gtk/WaylandBuffer.h(lines 27-93):mBufferSurfaceis at 0x48, which matches the fault address andmov rcx, qword [rcx + 0x48]. The searchfoxfield_layouttool returned no rows for this class. - pass mechanism —
SetColorPropertiesalready 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.
Comment 1•1 day ago
|
||
Set release status flags based on info from the regressing bug 2084900
| Assignee | ||
Comment 2•1 day ago
|
||
Updated•1 day ago
|
Comment 5•1 day ago
|
||
| bugherder | ||
| Assignee | ||
Updated•19 hours ago
|
Comment 6•16 hours ago
|
||
| bugherder | ||
Description
•