~70 crashes and 1 crash per installation, all crashes with intel cpus. Oldest crashes with Gecko 83, none with 84, then again with 85+.

Crash report: https://crash-stats.mozilla.org/report/index/2dc5a79e-9452-44a0-8f3d-e9e850210204

Reason: EXC_BAD_ACCESS / KERN_INVALID_ADDRESS

Top 10 frames of crashing thread:

0 XUL mozilla::layers::AsyncImagePipelineManager::ApplyAsyncImageForPipeline gfx/layers/wr/AsyncImagePipelineManager.cpp:500
1 XUL mozilla::layers::WebRenderBridgeParent::ProcessWebRenderParentCommands gfx/layers/wr/WebRenderBridgeParent.cpp:1405
2 XUL mozilla::layers::WebRenderBridgeParent::RecvSetDisplayList gfx/layers/wr/WebRenderBridgeParent.cpp:1163
3 XUL mozilla::layers::PWebRenderBridgeParent::OnMessageReceived ipc/ipdl/PWebRenderBridgeParent.cpp:403
4 XUL mozilla::layers::PCompositorManagerParent::OnMessageReceived ipc/ipdl/PCompositorManagerParent.cpp:205
5 XUL mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2077
6 XUL mozilla::ipc::MessageChannel::MessageTask::Run ipc/glue/MessageChannel.cpp:1956
7 XUL nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1165
8 XUL mozilla::ipc::MessagePumpForNonMainThreads::Run ipc/glue/MessagePump.cpp:332
9 XUL MessageLoop::Run ipc/chromium/src/base/message_loop.cc:310

Andrew (calling because you know this code well), I wonder why we aren't seeing them on nightly. Was there a fix there that we forgot to uplift to release?

Looking through change history, the most related one appears to be https://phabricator.services.mozilla.com/D93179, which touches ApplyAsyncImageForPipeline, is specifically aimed at macOS, and the date (October 2020) seems right about the start of the crashstats graph.
Matt, can this change be related?

https://crash-stats.mozilla.org/signature/?signature=mozilla%3A%3Alayers%3A%3AAsyncImagePipelineManager%3A%3AApplyAsyncImageForPipeline&product=Firefox&date=%3E%3D2021-02-11T22%3A05%3A00.000Z&date=%3C2021-02-18T22%3A05%3A00.000Z&_sort=-date

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

Looking through change history, the most related one appears to be https://phabricator.services.mozilla.com/D93179, which touches ApplyAsyncImageForPipeline, is specifically aimed at macOS, and the date (October 2020) seems right about the start of the crashstats graph.
Matt, can this change be related?

D93179 changed how flags are handled. Then it seems not related to the crash. Crash reports did not show correct place of the crash :(

By looking into m-c, found that, MacIOSurfaceTextureHostOGL does not handle MacIOSurface look up failure. Bug 1694089

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

By looking into m-c, found that, MacIOSurfaceTextureHostOGL does not handle MacIOSurface look up failure. Bug 1694089

Do you have an idea of how that failure would cause this crash?

My guess was that the line in the crash report is pointing to the destructor of one of the stack RAII variables.

Possibly mAPI was nullptr? I can't see how that could happen though.

(In reply to Matt Woodrow (:mattwoodrow) from comment #6)

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

By looking into m-c, found that, MacIOSurfaceTextureHostOGL does not handle MacIOSurface look up failure. Bug 1694089

Do you have an idea of how that failure would cause this crash?

I thought that the following might cause a crash if mSurface is not valid.
https://searchfox.org/mozilla-central/rev/f47a4b67643b3048ef9a2e2ac0c34edf6d1ebff3/gfx/layers/opengl/MacIOSurfaceTextureHostOGL.cpp#200

deleted

Crash did not happen since 87.