Rust panic - Unsupported number of YUV planes: 2
Categories
(Core :: Graphics: WebRender, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox86 | --- | disabled |
| firefox87 | --- | disabled |
| firefox88 | --- | disabled |
| firefox89 | --- | fix-optional |
People
(Reporter: whimboo, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: crash, regression, regressionwindow-wanted)
Crash Data
I can replicate the crash by running the steps from bug 1693011 comment 10:
$ # repro steps include an HTML test asset from playwright repo. Checkout tag to make repro future-proof. $ git clone https://github.com/microsoft/playwright && git checkout v1.9.0 $ $ /Applications/Firefox\ Nightly.app/Contents/MacOS/firefox --headless file:///$PWD/playwright/test/assets/video.html -profile ./profile
Crash report: https://crash-stats.mozilla.org/report/index/6b867837-cc8d-4f1e-acc3-b193a0210308
MOZ_CRASH Reason: unsupported number of YUV planes: 2
Top 10 frames of crashing thread:
0 XUL RustMozCrash mozglue/static/rust/wrappers.cpp:17
1 XUL mozglue_static::panic_hook mozglue/static/rust/lib.rs:89
2 XUL core::ops::function::Fn::call /builds/worker/fetches/rustc/lib/rustlib/src/rust/library/core/src/ops/function.rs:70
3 XUL std::panicking::rust_panic_with_hook library/std/src/panicking.rs:595
4 XUL std::panicking::begin_panic_handler::{{closure}} library/std/src/panicking.rs:497
5 XUL std::sys_common::backtrace::__rust_end_short_backtrace library/std/src/sys_common/backtrace.rs:141
6 XUL rust_begin_unwind library/std/src/panicking.rs:493
7 XUL std::panicking::begin_panic_fmt library/std/src/panicking.rs:435
8 XUL webrender::compositor::sw_compositor::SwCompositor::queue_composite gfx/wr/webrender/src/compositor/sw_compositor.rs:1151
9 XUL <webrender::compositor::sw_compositor::SwCompositor as webrender::composite::Compositor>::start_compositing gfx/wr/webrender/src/compositor/sw_compositor.rs:1705
It's a regression started some time on March 5th. I will do a regression test to figure out the exact changeset.
|
Reporter | |
Comment 1•4 years ago
|
||
It doesn't look to be a recent regression. Maybe it's around all the time since software webrender is available. I don't have the time to dig further into the regression test.
|
|
Reporter | |
Comment 2•4 years ago
|
||
It actually started with the first Firefox Nightly 86.0 build on Dec 15th. Here the pushlog for that Nightly build:
panic!("unsupported number of YUV planes: {}", info.yuv_planes)
|
||
Updated•4 years ago
|
|
||
Updated•4 years ago
|
|
||
Updated•4 years ago
|
|
||
Comment 3•4 years ago
|
||
Can't we get YUV surfaces with a plane count of 2?
|
||
Updated•4 years ago
|
|
|
||
Comment 4•4 years ago
|
||
Matt, it looks like in headless mode we fall back to RenderCompositorSWGL instead of RenderCompositorNativeSWGL. Could we detect if that happens and either avoid using MacIOSurface or at least not use an NV12/YUV422 surface? Or alternatively is the problem here that we fell back to RcSWGL in the first place?
|
||
Updated•4 years ago
|
|
||
Comment 5•4 years ago
|
||
(In reply to Lee Salzman [:lsalzman] from comment #4)
Matt, it looks like in headless mode we fall back to RenderCompositorSWGL instead of RenderCompositorNativeSWGL. Could we detect if that happens and either avoid using MacIOSurface or at least not use an NV12/YUV422 surface? Or alternatively is the problem here that we fell back to RcSWGL in the first place?
I think we've mostly assumed that we'll always get RenderCompositorNativeSWGL on MacOS, so it would be nice to maintain that.
Failing that, it seems like the problem is that we unconditionally assume that our RenderCompositor can handle 2-plane MacIOSurfaces directly, and that's not true in this case - https://searchfox.org/mozilla-central/rev/166dfa51ee50207a253fc577b9a596e64f24258c/gfx/layers/opengl/MacIOSurfaceTextureHostOGL.cpp#265
|
||
Updated•4 years ago
|
|
||
Comment 7•1 year ago
|
||
Closing because no crashes reported for 12 weeks.
Description
•