1691376 - AVIF decoding occasionally crashes Firefox tab

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect, P3)

Description

[unallied.com]

Attachment: profileBanner.avif

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0

Steps to reproduce:

Open an AVIF image in its own tab (e.g. file:///C:/Users/user/Desktop/profileBanner.avif).
Refresh (F5) until tab crashes (usually takes ~5-15 attempts). It doesn't matter how fast or slow you refresh (tested with ~200ms delay and ~4 second delay).

I've had the best luck in getting the tab to crash with the attached image. I tried to crash the tab with smaller image sizes but was unable to replicate this bug. This image doesn't crash on Chrome.

Alternatively, include an avif image as a CSS background-image: url() and refresh the page or the url itself (e.g. swapping between webp and avif image urls).

Other details:
OS: Microsoft Windows 10 Pro Build 19041
CPU: AMD Ryzen 7 3700X 8-Core Processor 3.59 GHz
GPU: GeForce RTX 2070 SUPER with GeForce Game Ready Driver version 460.79

Actual results:

The tab crashed and brought me to Firefox's "Tab crash reporter".

Expected results:

The tab shouldn't crash, and the image should load.

Comment 1

[Pascal Chevrel:pascalc (PTO until April 26)]

Reporter, could you provide crash ID links caused by this bug in about:crashes please? thanks

Comment 2

[unallied.com]

I'm having trouble submitting a crash ID for this particular crash. It's not appearing in about:crashes. Maybe it has to do with how this crash is occurring?

I'm testing this without any Extensions in Incognito. The only Plugins I have enabled are "OpenH264 Video Codec provided by Cisco Systems" and "Widevine Content Decryption Module provided by Google Inc.".

Is there any other info I can provide that would be helpful?

Comment 3

[unallied.com]

I've had reports that this image was also crashing Chrome tabs prior to (roughly) version 88.0.4324.146. It was crashing as recently as Chrome version 88.0.4324.96 (Official Build) (x86_64).

NB: Refreshing this page is enough to cause the tab crash if you're on a slightly older Chrome or any of the latest versions of Firefox with AVIF support. You may need to refresh 10-15+ times (though usually less).

Comment 4

[unallied.com]

I managed to get a crash (only once out of ~500 attempts) on Firefox running inside of WSL 2. Luckily this crash generated a crash report (still no crash reports from Firefox running on Windows): https://crash-stats.mozilla.org/report/index/f63052f8-7f7d-4c12-8f7f-eb58c0210209#tab-details.

I have no idea why it was so much harder to crash the tab on Linux.

Comment 5

[Andrei Purice]

Reproduced on Firefox Nightly 87.0a1 (2021-02-11) and beta 86.0b9 but not on Release 85.0.2 as when trying to open the file the download prompt will be triggered. Though the crash happens with ease it doesn't generate any crash reports for me.

Setting up the flags for this issue and assigning it a component in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one.

I'm not sure if this is a regression or not since on the older versions below 86 the file can't be opened but instead is downloaded. Every time you select the browser in order to open the file it just prompts the download again restarting the process.

Assigning it a severity of S2.

Comment 6

[Jon Bauman [:jbauman:]]

I haven't been able to reproduce this on macOS with 86.0b2 or Nightly 87.0a1 (2021-02-10) or Chrome Version 88.0.4324.96 (Official Build) (x86_64). Looking at the crash, it appears to be in dav1d code, so I'm talking with the developers of that library to track it down.

If you can still reproduce it, one way to validate that it's a dav1d-specific issue is to switch image.avif.use-dav1d to false in about:config and see if it's still reproducible. Could you let us know what you find?

Comment 7

[unallied.com]

I think your theory about dav1d is right. I switched to image.avif.use-dav1d = false, and was unable to reproduce the issue even after 500 refreshes.

After switching back to image.avif.use-dav1d = true, I was able to reproduce the crash immediately (1st, 2nd, and 11th attempt).

Comment 8

[Jon Bauman [:jbauman:]]

There's a fix for this issue which will hopefully land soon https://code.videolan.org/videolan/dav1d/-/merge_requests/1169.

Also, it appears to only occur with 444. Given that and the fact that there's a workaround, I'm going to lower the severity accordingly.

Comment 9

[Jon Bauman [:jbauman:]]

Assuming the issue is fixed on the dav1d side, this will be resolved when the next update occurs for bug 1688992. That's scheduled to happen on February 22nd, the beginning of the next Nightly cycle. Once that happens, we can confirm it fixed in Nightly and it will be released in 88. Given the workaround and the relative infrequency, I don't think we should incur the additional risk of an uplift.

Comment 10

[Jon Bauman [:jbauman:]]

We've updated the dav1d version in Firefox to one that has the intended fix for this issue. Could you try reproducing it with a new nightly version?

Comment 11

[unallied.com]

Thanks, Jon. It looks like this bug is fixed. I can't reproduce the crash on the latest nightly (88.0a1), even with dav1d enabled.

Comment 12

[Jon Bauman [:jbauman:]]

Huzzah!

Thanks so much for the bug report and putting in the extra effort to get the crash details