1828726 - Crash in [@ MacIOSurface::~MacIOSurface]

Status: RESOLVED DUPLICATE of bug 1827340

(Core :: Graphics, defect)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

11 crash reports for Firefox 114 (Nightly) and 113 (Beta) on macOS versions 10.12-10.14.

Crash report: https://crash-stats.mozilla.org/report/index/13535f8f-77fe-4a5e-9656-691f10230418

MOZ_CRASH Reason: MOZ_RELEASE_ASSERT(!IsLocked()) (Destroying locked surface)

Top 10 frames of crashing thread:

0  XUL  MacIOSurface::~MacIOSurface  gfx/2d/MacIOSurface.cpp:31
1  XUL  mozilla::detail::RefCounted<MacIOSurface,  const  mfbt/RefCounted.h:255
1  XUL  mozilla::RefPtrTraits<MacIOSurface>::Release  mfbt/RefPtr.h:54
1  XUL  RefPtr<MacIOSurface>::ConstRemovingRefPtrTraits<MacIOSurface>::Release  mfbt/RefPtr.h:420
1  XUL  RefPtr<MacIOSurface>::~RefPtr  mfbt/RefPtr.h:85
1  XUL  RefPtr<MacIOSurface>::~RefPtr  mfbt/RefPtr.h:83
1  XUL  mozilla::wr::RenderMacIOSurfaceTextureHost::~RenderMacIOSurfaceTextureHost  gfx/webrender_bindings/RenderMacIOSurfaceTextureHost.cpp:50
2  XUL  mozilla::wr::RenderMacIOSurfaceTextureHost::~RenderMacIOSurfaceTextureHost  gfx/webrender_bindings/RenderMacIOSurfaceTextureHost.cpp:47
2  XUL  mozilla::wr::RenderMacIOSurfaceTextureHost::~RenderMacIOSurfaceTextureHost  gfx/webrender_bindings/RenderMacIOSurfaceTextureHost.cpp:47
3  XUL  mozilla::wr::RenderTextureHost::Release  gfx/webrender_bindings/RenderTextureHost.h:42

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 5 desktop browser crashes on Mac on beta

:bhood, could you consider increasing the severity of this top-crash bug?

For more information, please visit auto_nag documentation.

Comment 2

[Ryan VanderMeulen [:RyanVM]]

Sotaro, is this something you might have any ideas about?

Comment 3

[Sotaro Ikeda [:sotaro OOO until July/21]]

MacIOSurface of RenderMacIOSurfaceTextureHost is locked by RenderTextureHostSWGL::UpdatePlanes(). And it is unlocked by RenderTextureHostSWGL::UnlockSWGL(). It is used only wit software WebRender.

Then it seemed that there was a case that locked MacIOSurface was not unlocked.

Comment 4

[Sotaro Ikeda [:sotaro OOO until July/21]]

:lsalzman, do you know if there could be a case that the UnlockSWGL() is not called.

Comment 5

[Sotaro Ikeda [:sotaro OOO until July/21]]

This might be similar to Bug 1827340.

Comment 6

[Kelsey Gilbert [:jgilbert]]

Sounds bad, so S2.
+bradwerth

Comment 7

[Brad Werth [:bradwerth]]

I don't know if I can contribute much here. It seems there are only a few ways that we could fail to pair a LockSWGL call with a UnlockSWGL call:

One way this could happen is if, within the WR compositor, we call ExternalImageHandler.lock but don't call 'unlock'. Looking through the callsites it seems like it all matches up, but there's some strangeness. save_capture does a loop followed by a loop over deferred_images, locking in the first loop and unlocking in the second. It's weird, but there's no way for the Vec to change between loops. And in Renderer.prepare_gpu_cache we do our locks on a Vec of frame.deferred_resolves, but then do the unlocks on a HashMap of texture_resolver.external_images which should have all the indices of the deferred_resolves, but it's not validated there. It looks like it checks out, but the safety guarantee is not obvious.

Another way this could happen is if there is a call to set_external_image_handler between the calls to lock and unlock, but I can't find any evidence of such a thing.

Comment 8

[Sotaro Ikeda [:sotaro OOO until July/21]]

(In reply to Sotaro Ikeda [:sotaro] from comment #5)

This might be similar to Bug 1827340.

Bug 1827340 fix might address the problem.

Comment 9

[Lee Salzman [:lsalzman]]

Sotaro, is this possibly related to bug 1812982 too, where we seem to have cases where picture-in-picture causes the same external image to be locked multiple times in a single frame? That seems to at bottom be caused by a RenderBufferTextureHost being created only once for multiple windows using the same image, which screws up all the locking?

Comment 10

[Sotaro Ikeda [:sotaro OOO until July/21]]

(In reply to Sotaro Ikeda [:sotaro] from comment #5)

This might be similar to Bug 1827340.

Bug 1827340 seemed to address the problem on beta.