Closed Bug 1707832 Opened 3 years ago Closed 3 years ago

macOS Crash in [@ mozilla::layers::NativeLayerCA::NextSurface]

Categories

(Core :: Graphics: WebRender, defect)

defect

Tracking

()

RESOLVED FIXED
90 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox88 --- wontfix
firefox89 --- wontfix
firefox90 --- fixed

People

(Reporter: aryx, Assigned: bradwerth)

References

(Regression)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

69 crashes for Firefox 87, there were fewer crashes for Firefox 86 which had the fix from bug 1686834. The frequency increased since early February but on a low level.

Crash report: https://crash-stats.mozilla.org/report/index/473190f6-e1cb-4aa9-8945-ea4660210426

MOZ_CRASH Reason: MOZ_RELEASE_ASSERT(newSurf) (NextSurface IOSurfaceCreate failed to create the surface.)

Top 10 frames of crashing thread:

0 XUL mozilla::layers::NativeLayerCA::NextSurface gfx/layers/NativeLayerCA.mm:643
1 XUL mozilla::layers::NativeLayerCA::NextSurfaceAsFramebuffer gfx/layers/NativeLayerCA.mm:718
2 XUL mozilla::wr::RenderCompositorNativeOGL::Bind gfx/webrender_bindings/RenderCompositorNative.cpp:518
3 XUL <webrender_bindings::bindings::WrCompositor as webrender::composite::Compositor>::bind gfx/webrender_bindings/src/bindings.rs:1310
4 XUL webrender::renderer::Renderer::draw_frame gfx/wr/webrender/src/renderer/mod.rs:4641
5 XUL webrender::renderer::Renderer::render_impl gfx/wr/webrender/src/renderer/mod.rs:2159
6 XUL webrender::renderer::Renderer::render gfx/wr/webrender/src/renderer/mod.rs:1894
7 XUL wr_renderer_render gfx/webrender_bindings/src/bindings.rs:636
8 XUL mozilla::wr::RenderThread::UpdateAndRender gfx/webrender_bindings/RenderThread.cpp:486
9 XUL mozilla::wr::RenderThread::HandleFrameOneDoc gfx/webrender_bindings/RenderThread.cpp:341

Brad, does it give us more information to look at the original crash?

Severity: -- → S3
Flags: needinfo?(bwerth)
Regressed by: 1685046
Has Regression Range: --- → yes

This closes the only way that ObtainSurfaceFromPool could return a null
surface, unless the macOS API IOSurfaceCreate returns a null reference.
There's no evidence that this API should ever return null. Consequently, since
NativeLayerCA::NextSurface is the only caller of this function, this patch
removes the MOZ_RELEASE_ASSERTS there.

A potential follow-up would be to investigate the entries that are put into
mAvailableEntries and check that the surfaces are non-null at the time of
their insertion.

Assignee: nobody → bwerth
Status: NEW → ASSIGNED
Flags: needinfo?(bwerth)

Thanks Brad! Do you think you have the time to try investigating this further by putting the suggested checks in place?

Flags: needinfo?(bwerth)

(In reply to Dzmitry Malyshau [:kvark] from comment #3)

Thanks Brad! Do you think you have the time to try investigating this further by putting the suggested checks in place?

Yes, I'll update the patch with an approach that follows the suggestion by mstange.

Flags: needinfo?(bwerth)
Attachment #9219360 - Attachment description: Bug 1707832: Ensure that ObtainSurfaceFromPool only reuses valid surfaces. → Bug 1707832: Ensure that SurfacePoolCA doesn't store or give out null recycled surfaces.
Pushed by bwerth@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/79a02e8fc876
Ensure that SurfacePoolCA doesn't store or give out null recycled surfaces. r=mstange
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 90 Branch

The patch landed in nightly and beta is affected.
:bradwerth, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(bwerth)
Flags: needinfo?(bwerth)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: