Closed Bug 1739910 Opened 2 years ago Closed 2 years ago

Crash in [@ dav1d_cdef_filter_8x8_8bpc_avx512icl], [@ dav1d_lpf_h_sb_y_8bpc_ssse3]

Categories

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

defect

Tracking

()

RESOLVED FIXED
96 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox93 --- unaffected
firefox94 --- unaffected
firefox95 --- unaffected
firefox96 + fixed

People

(Reporter: aryx, Unassigned)

References

(Regression)

Details

(Keywords: crash, regression)

Crash Data

2k crashes from 5 installations so far, all with Firefox 96.0a1 20211107095110 on Windows.

Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/bfb601e0-9c57-49c7-b6f6-e4ca70211107

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0 xul.dll dav1d_cdef_filter_8x8_8bpc_avx512icl 
1 xul.dll decode_b third_party/dav1d/src/decode.c:2248
2  @0x18d9e2f73e7 
3 xul.dll _tailMerge_d3dcompiler_47.dll 
4 xul.dll dav1d_copy_lpf_8bpc media/libdav1d/8bd_lf_apply_tmpl.c:164
5  @0x18d9edc7fff 
6 xul.dll insert_tasks third_party/dav1d/src/thread_task.c:157
7 xul.dll dav1d_worker_task third_party/dav1d/src/thread_task.c:610
8 xul.dll thread_entrypoint third_party/dav1d/src/win32/thread.c:59
9 ucrtbase.dll thread_start<unsigned int , 1> 
Flags: needinfo?(jbauman)

I ran into this while watching an AV1 video on Youtube. The video was extremely choppy (varying between several frames per second and several seconds per frame); I think it started actually crashing (eyeballing about:crashes, probably a hundred or two crashes over the span of two minutes before I closed the tab) when I tried to go backward in the video (left arrow key, as that sometimes gets the video to unfreeze; audio was fine).

Tiger lake CPU (hence the AVX-512). Please let me know if there's anything I can do to help.

In summary: as far as I can tell, this makes AV1 video basically unplayable if you are on AVX-512; the only reason this is across so few installations is because of the (presumably) small overlap of AVX-512, AV1, and Nightly.

I get this consistently about a minute and a half into this video: https://www.youtube.com/watch?v=lM9BR55nA2U

Downloading the video and putting it through dav1d manually does not appear to cause any errors.

Crash Signature: [@ dav1d_cdef_filter_8x8_8bpc_avx512icl] → [@ dav1d_cdef_filter_8x8_8bpc_avx512icl] [@ dav1d_lpf_h_sb_y_8bpc_ssse3]
Summary: Crash in [@ dav1d_cdef_filter_8x8_8bpc_avx512icl] → Crash in [@ dav1d_cdef_filter_8x8_8bpc_avx512icl], [@ dav1d_lpf_h_sb_y_8bpc_ssse3]

Bug 1738736 got backed out hence the issue should be resolved in the next Nightly.

No new crashes from latest nightly , closing bug

Target Milestone: --- → 96 Branch
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED

I'm trying to reproduce this to see if it's something specific in the way Firefox is using dav1d.

For convenience, here's the nightly that was showing up in the crash reports: https://ftp.mozilla.org/pub/firefox/nightly/2021/11/2021-11-07-09-51-10-mozilla-central/

Justin, if you don't mind sharing, what platform are you running on? So far, I haven't had success on macOS with a CPU that has SSE3, but no AVX512.

Flags: needinfo?(jbauman) → needinfo?(1justinpeter)

I'm running an Intel Tiger lake CPU (11th gen laptop, with AVX-512) on Windows 10 (20H2). I ran into this issue anywhere between a few seconds and a couple minutes into any Youtube video encoded with AV1[0] (which was a surprising number). I jumped into the Dav1d IRC last night and managed to figure out how to run a couple videos (downloaded from Youtube) through the latest build of Dav1d[1], and that didn't result in any errors or decoding differences we could easily find.

For what it's worth, I'm not sure if the SSSE3 crash is related - it only happened on a single installation, and it looks to be one nightly before the AVX-512 crashes started showing up. Also, if your CPU has AVX2 (which is most CPUs since ~2013) Dav1d is probably using that over SSSE3.

--

[0] To verify if a video's using AV1: right click the video -> stats for nerds -> codec should be av01 (not avc1), which should be followed by the number 397/398/399 depending on resolution.

[1] Which was a slightly newer version than the version updated to in Firefox, but neither of the newer commits should have affected AVX-512 decoding.

Flags: needinfo?(1justinpeter)

An afterthought: I didn't look into this very closely, but I didn't try playing the AV1 video in Firefox by itself (as a local file, rather than through Youtube). If that could be useful I'll download the older nightly later tonight and see what happens when I try that.

From talking with the dav1d folks, it sounds like it's probably an issue on that side of things. Will let you know if that doesn't pan out.

Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.