2063809 - Crash in [@ ff_vk_exec_add_dep_frame]

Status: RESOLVED FIXED

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

Description

[Calixte Denizet (:calixte)]

Crash report: https://crash-stats.mozilla.org/report/index/2cd465d2-8027-4a85-b523-2baec0260815

Crash Reason:

SIGSEGV / SEGV_MAPERR at 0x0000000000000000

Top 10 frames:

0  libavcodec.so.60  ff_vk_exec_add_dep_frame
1  libavcodec.so.60  ff_vk_decode_frame
2  libavcodec.so.60  vk_h264_end_frame
3  libavcodec.so.60  ff_h264_field_end
4  libavcodec.so.60  h264_decode_frame
5  libavcodec.so.60  decode_receive_frame_internal
6  libavcodec.so.60  avcodec_send_packet
7  libxul.so  mozilla::FFmpegVideoDecoder<60>::DoDecode(mozilla::MediaRawData*, unsigned char*...  dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:1581
8  libxul.so  mozilla::FFmpegDataDecoder<53>::DoDecode(mozilla::MediaRawData*, bool*, nsTArray...  dom/media/platforms/ffmpeg/FFmpegDataDecoder.cpp:358
9  libxul.so  mozilla::FFmpegDataDecoder<60>::ProcessDecode(mozilla::MediaRawData*)  dom/media/platforms/ffmpeg/FFmpegDataDecoder.cpp:312

There are 5 crashes (from 2 installations) in nightly 156 with buildid 20260814214318.

Clouseau analysis (automated, 97% 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:

Bug 2045970 (585a77d8786a) enables FEATURE_HARDWARE_VIDEO_DECODING_VULKAN by default for NVIDIA drivers >= 580.76.5.0 on Linux Nightly and rewires FFmpegVideoDecoder<LIBAV_VER>::InitVulkanDecoder's gate to gfx::gfxVars::CanUseVulkanHardwareVideoDecoding(), which for this crash's exact hardware (NVIDIA 0x2504, driver 610.43.2.0) newly routes H.264 decode through FFmpeg's Vulkan hwaccel (ff_vk_decode_frame/ff_vk_exec_add_dep_frame) instead of software/VAAPI decode. That FFmpeg Vulkan code and Mozilla's new shared-VulkanDeviceHolder lifetime model are freshly exposed to this hardware class, making a rough-edge null deref in the exec/dependency-frame tracking plausible, though the exact null field is inside system libavcodec.so and unverifiable from mozilla-central.

The crash build (20260814214318) is one day after this changeset landed (2026-08-13) on the nightly channel, and the crashing GPU/driver falls exactly within the newly-enabled DeviceFamily::NvidiaAll + driver>=580.76.5.0 blocklist bound this changeset introduces — a specific, non-coincidental hardware/timing match rather than mere window membership.

Suspected regressor: 585a77d8786a (gh) (bug 2045970) by stransky.

Code references:

• widget/gtk/GfxInfo.cpp:1344
• widget/gtk/GfxInfo.cpp:1341

What the automated skeptic pass checked (its own words — a pass means the check succeeded, which is not always support for the conclusion):

• unverifiable mechanism — The exact null-deref field inside ff_vk_exec_add_dep_frame is in system libavcodec.so, outside mozilla-central's index; only the fact that this code path became newly reachable for this hardware is verifiable, not the internal FFmpeg defect itself.
• pass device_family_match — 0x2504 is NVIDIA; DeviceFamily::NvidiaAll matches all NVIDIA device IDs and driver 610.43.2.0 >= the 580.76.5.0 threshold added by this changeset.
• pass pref_newly_enabled_on_nightly — Changeset title says 'Enable Vulkan decode on Nightly'; StaticPrefList.yaml diff flips a pref default to @IS_NIGHTLY_BUILD@ adjacent to the new force-enabled pref, consistent with this being newly on rather than already-on before the changeset.
• pass hdr_metadata_candidates_unrelated — bug 2057751's SetHDRMetadata changes are downstream of decode (surface/compositor), not in the pre-decode avcodec_send_packet/hwaccel-context path, so judged non-noise-but-unrelated to this specific null deref.

:stransky, can you have a look please?

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.

Comment 1

[Tymur Boiko]

At first glance this looks like an FFmpeg Vulkan Video H.264 issue, not Gecko (possibly stream-dependent, not necessarily broken content). vk_h264_start_frame walks the H.264 DPB and fills Vulkan reference slots; ff_vk_decode_frame then calls ff_vk_exec_add_dep_frame on each, which dereferences a listed ref that has no Vulkan frame. A link to the video would help.

Comment 2

[Tymur Boiko]

Yes, this is a FFmpeg n6.1.1 (from 10/2023) specific issue for a specific hw capabilities.
See: https://trac.ffmpeg.org/ticket/10847
FFmpeg ca591e6b fixed the above in origin/release/7.1 and tags n7.1+
So, we may need to gate H264 for this case (I will follow up a patch).

Comment 3

[Tymur Boiko]

Attachment: Bug 2063809 - Skip Vulkan H.264 on FFmpeg < n7.1 for COINCIDE without SEPARATE_REFERENCE_IMAGES. r=alwu,stransky

FFmpeg before n7.1 sets layered_dpb with dedicated_dpb=0 for that
capability combo and later SIGSEGVs in ff_vk_exec_add_dep_frame. Query
the already-created phys_dev and fall back so VA-API can take the stream.

The skip itself is H.264-only and only for libavcodec < 61.19.100.

Vulkan video caps are per profile (codec, IDC, layout, chroma, depth),
not per GPU. Each slot stores that key and is re-queried when
ShouldSkip asks for a different combination. That is enough for this
bug: COINCIDE / SEPARATE_REFERENCE_IMAGES do not flip across those
variants on the drivers we care about. It is not a multi-entry caps
table; a later gate for another profile must change the key or query
that slot again.

SPS profile_idc values that Vulkan headers do not name (High 10,
High 4:2:2, old High 4:4:4) are mapped to HIGH. Bit depth and chroma
are already in the key. Passing the raw IDC can fail the query and
fail open, which would skip the workaround.

• vkGetPhysicalDeviceVideoCapabilitiesKHR is loaded into the existing
  instance-function cache and kept out of IsLoaded(), because a missing
  optional PFN must not fail decoder init.
• Video capabilities live on that same cache object (not a second key).
• The probe is lazy: only H.264 on FFmpeg < n7.1 is queried, then
  cached. Profile IDC, progressive vs interlaced, chroma format, and
  chroma bit depth come from the SPS; luma depth from mInfo.mColorDepth.
  Later decoder instances in the same process and wrapper reuse that
  key. n7.1+ and other codecs do not query.
• HEVC / AV1 / VP9 slots stay as lazy Ensure arms for a later gate.
• The skip reads mCaps / mDecodeCaps directly; those are the structs
  we passed in pNext.
• A failed query marks that slot invalid and we fail open, so a
  driver/profile mismatch does not block Vulkan on a later FFmpeg.

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

For more information, please visit BugBot documentation.

Comment 5

[BugBot [:suhaib / :marco]]

This bug has been marked as a regression. Setting status flag for Nightly to affected.

Comment 6

[Tymur Boiko]

A patch is ready for review/landing. Awaiting approval

Comment 7

[Tymur Boiko]

Can we land this patch?

Comment 8

[Paul Adenot (:padenot)]

Queued for landing, thanks!

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/dbab9f62b649
https://hg.mozilla.org/integration/autoland/rev/d106f6534f60
Skip Vulkan H.264 on FFmpeg < n7.1 for COINCIDE without SEPARATE_REFERENCE_IMAGES. r=stransky

Comment 10

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/d106f6534f60