1975607 - Crash in [@ mozilla::layers::TextureClientRecycleAllocator::CreateOrRecycle]

Status: NEW

(Core :: Audio/Video: Playback, defect, P3)

Description

[Andrew McCreight [:mccr8]]

Crash report: https://crash-stats.mozilla.org/report/index/7f4e4ec0-17f2-48c2-9649-0e5100250702

Reason:

EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames:

0  xul.dll  mozilla::layers::TextureClientRecycleAllocator::CreateOrRecycle(mozilla::laye...  gfx/layers/client/TextureClientRecycleAllocator.cpp:169
1  xul.dll  mozilla::layers::SharedPlanarYCbCrImage::CreateEmptyBuffer(mozilla::layers::P...  gfx/layers/ipc/SharedPlanarYCbCrImage.cpp:126
2  xul.dll  mozilla::layers::SharedPlanarYCbCrImage::CopyData(mozilla::layers::PlanarYCbC...  gfx/layers/ipc/SharedPlanarYCbCrImage.cpp:87
3  xul.dll  mozilla::MediaResult::MediaResult(nsresult, nsTSubstring<char> const&, mozill...  dom/media/MediaData.cpp:325
3  xul.dll  mozilla::VideoData::SetVideoDataToImage(mozilla::layers::PlanarYCbCrImage*, m...  dom/media/MediaData.cpp:0
4  xul.dll  nsTSubstring<char>::~nsTSubstring()  xpcom/string/nsTSubstring.h:328
4  xul.dll  mozilla::MediaResult::~MediaResult()  dom/media/MediaResult.h:29
4  xul.dll  mozilla::WMFVideoMFTManager::CreateBasicVideoFrame(IMFSample*, long long, moz...  dom/media/platforms/wmf/WMFVideoMFTManager.cpp:0
5  xul.dll  mozilla::WMFVideoMFTManager::Output(long long, RefPtr<mozilla::MediaData>&)  dom/media/platforms/wmf/WMFVideoMFTManager.cpp:922
6  xul.dll  mozilla::WMFMediaDataDecoder::ProcessOutput(nsTArray<RefPtr<mozilla::MediaDat...  dom/media/platforms/wmf/WMFMediaDataDecoder.cpp:145

Null derefs. The majority of the crashes have video URLs from https://www.bilibili.com . The null deref crash is on a line with a ton of dereferences, so I'm not sure which is null, but for bug 1672621 it was the allocator, it looks like.

Comment 1

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit BugBot documentation.

Comment 2

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

[Jim Mathies [:jimm]]

A null-dereference crash in TextureClientRecycleAllocator::CreateOrRecycle is occurring for Windows users watching video on bilibili.com. The crash happens when attempting to call IPCOpen() on a null allocator retrieved from a pooled TextureClient. This is closely related to Bug 1672621 (RESOLVED FIXED in FF84), which patched the same function for a slightly different code path — the current crash appears on the software/YCbCr path (SharedPlanarYCbCrImage) rather than the D3D11 path.

This is a confirmed crash (keyword: crash) affecting real users on Windows, primarily on bilibili.com. It is a null-dereference — a class of crash that tends to be widespread once the conditions are met. The crash is from Windows Media Foundation's software decode path (WMFVideoMFTManager::CreateBasicVideoFrame → SharedPlanarYCbCrImage::CopyData → CreateEmptyBuffer), suggesting it could affect any video decoding via WMF software fallback. The original D3D11 path was fixed in 2020 (Bug 1672621), but the same guard was not applied to the pooled client's GetAllocator() call at line 169.

Codebase Investigation

Relevant Files Examined

• gfx/layers/client/TextureClientRecycleAllocator.cpp:152–207 — CreateOrRecycle implementation
• gfx/layers/ipc/SharedPlanarYCbCrImage.cpp:82–135 — CopyData / CreateEmptyBuffer
• gfx/layers/client/TextureClient.h:611 — GetAllocator() returns raw mAllocator pointer (can be null)

Findings

The crash is at TextureClientRecycleAllocator.cpp:169:

if (!textureHolder->GetTextureClient()->GetAllocator()->IPCOpen() ||
    !aHelper.IsCompatible(textureHolder->GetTextureClient())) {

GetAllocator() returns the raw mAllocator pointer which can be null if the TextureClient was created without one (e.g., in the RDD process after GPU process crash, or during compositor teardown). There is currently a null check for the TextureForwarder at line 161, but no null check on the individual pooled client's allocator at line 169.

Bug 1672621 fixed the same crash on the D3D11 path by adding the early-exit at line 161. However, a pooled texture client that was created successfully could later have a null allocator when recycled. The fix should add:

if (!textureHolder->GetTextureClient()->GetAllocator() ||
    !textureHolder->GetTextureClient()->GetAllocator()->IPCOpen() || ...)

Or use a local variable to avoid double-dereference. Since the pooled client fails the check, it would be released via the TextureClientReleaseTask path (same as the IPCOpen() false branch), which is already correct behavior.

Suggested Investigation Areas

• gfx/layers/client/TextureClientRecycleAllocator.cpp:169 — Add null guard on GetAllocator()
• dom/media/platforms/wmf/WMFVideoMFTManager.cpp — CreateBasicVideoFrame is where SharedPlanarYCbCrImage is initialized; may be worth confirming whether the allocator can ever legitimately be null at this call site on Windows
• Cross-reference with dom/media/ipc/RemoteVideoDecoder.cpp (mentioned in Bug 1672621) — RDD process path may not set an allocator

Comment 4

[BugBot [:suhaib / :marco]]

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

• Top 10 desktop browser crashes on nightly

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

For more information, please visit BugBot documentation.

Comment 5

[BugBot [:suhaib / :marco]]

Based on the topcrash criteria, the crash signature linked to this bug is not a topcrash signature anymore.

For more information, please visit BugBot documentation.

Comment 6

[BugBot [:suhaib / :marco]]

Since the crash volume is low (less than 15 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit BugBot documentation.