1539709 - Crash in [@ I422ToARGBRow_SSSE3] - Philo.com

Status: RESOLVED WORKSFORME

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

Description

[Grayson Peddie [:graysonpeddie]]

This bug is for crash report bp-61e64872-34ee-48e1-891c-3a31d0190214. Crashes happen only in philo.com (a streaming service) regardless of Firefox version in Arch Linux (currently 66.0.1-1). So far, I have had no crashes in any other websites. Specifically, I was watching shows on-demand and crashes occurred frequently whenever I pause or resume.

Top 10 frames of crashing thread:

0 libxul.so I422ToARGBRow_SSSE3 media/libyuv/libyuv/source/row_gcc.cc:1945
1 libxul.so libyuv::I420ToARGBMatrix media/libyuv/libyuv/source/convert_argb.cc:110
2 libxul.so I420ToARGB media/libyuv/libyuv/source/convert_argb.cc:133
3 libxul.so mozilla::gfx::ConvertYCbCrToRGB32 gfx/ycbcr/yuv_convert.cpp:156
4 libxul.so mozilla::gfx::ConvertYCbCrToRGB gfx/ycbcr/YCbCrUtils.cpp:225
5 libxul.so mozilla::layers::PlanarYCbCrImage::GetAsSourceSurface gfx/layers/ImageContainer.cpp:616
6 libxul.so mozilla::layers::BasicImageLayer::Paint gfx/layers/basic/BasicImageLayer.cpp:74
7 libxul.so mozilla::layers::BasicLayerManager::PaintSelfOrChildren gfx/layers/basic/BasicLayerManager.cpp:688
8 libxul.so mozilla::layers::BasicLayerManager::PaintLayer gfx/layers/basic/BasicLayerManager.cpp
9 libxul.so mozilla::layers::BasicLayerManager::EndTransactionInternal gfx/layers/basic/BasicLayerManager.cpp:602

Comment 1

[Michael Froman [:mjf]]

Jean-Yves, who should take a look at this?

Comment 2

[Patricia Lawless]

Hi Nils, is this still a P1? (tracking for 68) Thanks!

Comment 3

[Nils Ohlmeier [:drno]]

Given that it depends on a P3 task of swapping out a third party library I don't see how this could have higher priority.

Jean-Yves is there something, e.g. updating libyuv, which we could do until bug 1540919 gets resolved?

Comment 4

[Jean-Yves Avenard [:jya]]

Frank, is this a crash type you're familiar with?

Comment 5

[Frank Barchard]

Thats a mature function, unlikely to have bugs. Its used by I420ToARGB, which is standard 3 plane YUV420 to ARGB.
The most common reasons for that are a miscalculation in the size of the buffers, or a dangling pointer, usually at shutdown time.

The user said it occurs during pause/resume.
So the use case is video decoder? When paused, likely something changes with the buffers to avoid rendering?

Comment 6

[Liz Henry (:lizzard)]

Too late for a fix in 68 but we can still take a patch for 69/70.

Comment 7

[Frank Barchard]

If you're able to find value parameters that make I420ToARGB crash I'd be happy to help.
But its likely on the calling end. Try adding some asserts that the pointers are value.

For jpeg I used to get a lot of crash reports, so before calling the jpeg decoder I added a ValidateJpeg that if nothing else, touches the memory.
Now the ValidateJpeg crashes if passed bad pointers, which is easier to debug. You could try something like that
Touch a few bytes from the I420 and ARGB buffers to ensure they are valid buffers.

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

Crashes here continue, including in automation: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=275109653&repo=try&lineNumber=31904

I suspect Frank is correct, and there's a race condition where we pass a bad buffer (or maybe size) to libyuv (dest buffer?), or we release the buffer after passing it off to libyuv (perhaps more likely). If we could catch it in rr, or maybe a debugger, we could try to figure out what happens more directly.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.

Comment 10

[Frank Barchard]

The function I422ToARGBRow_SSSE3 is now ported to AVX512. For 1000 iterations of 1280x720 on Skylake Xeon
AVX512 I420ToARGB_Opt (2050 ms)
AVX2 I420ToARGB_Opt (2533 ms)
SSSE3 I420ToARGB_Opt (3688 ms)
If there is still a crash report, it is likely to be the AVX2 version now, as SSSE3-only machines are becoming rare.