1799432 - Crash in [@ dav1d_wiener_filter7_8bpc_avx512icl]

Status: RESOLVED FIXED

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

Description

[Gabriele Svelto [:gsvelto]]

Crash report: https://crash-stats.mozilla.org/report/index/d7429779-e035-40d8-b733-7a3f90221104

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 2 frames of crashing thread:

0  xul.dll  dav1d_wiener_filter7_8bpc_avx512icl  
1  xul.dll  dav1d_wiener_filter7_8bpc_avx512icl  

Odd crash with unhelpful stack. The real crashing address appears to be the value contained by rcx. In this particular case the crashing address is 0x000002684557af60, the instruction causing it is vmovdqa32 zmmword [rcx + rbp * 1], zmm18 and indeed rcx contains 0x000002684557af8e.

What's odd is that Windows is reporting the address as 0xffffffffffffffff which is what happens when hitting a general protection fault, but the address is canonical so I don't know why it's been reported like that, it should be a regular access crash with the proper address.

Comment 1

[Gabriele Svelto [:gsvelto]]

Ah yes, the description of the vmovdqa32 instruction helps:

the operand must be aligned on a 32-byte boundary or a general-protection exception (#GP) will be generated

In this case the address we're accessing is not aligned to a 32-byte boundary (it's aligned to an 8-byte one).

Comment 2

[Jim Mathies [:jimm]]

Current RDD top crash in crash ping telemetry. Bumping to S2.

Comment 3

[Paul Adenot (:padenot)]

No crash in December since bug 1800912 landed (it landed on the 1st of December). Crashes on the 1st of December are with older builds.

Comment 4

[Paul Adenot (:padenot)]

I'm considering this fixed by bug 1800912 .