1657558 - Crash in [@ webrender::picture::PrimitiveList::add_prim]

Status: RESOLVED FIXED

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

Description

[Simon Giesecke [:sg] [he/him]]

This bug is for crash report bp-f32bcac8-b063-449b-8774-35da90200805.

Top 10 frames of crashing thread:

0 xul.dll webrender::picture::PrimitiveList::add_prim gfx/wr/webrender/src/picture.rs:4503
1 xul.dll webrender::scene_building::SceneBuilder::build_item gfx/wr/webrender/src/scene_building.rs:1224
2 xul.dll webrender::scene_building::SceneBuilder::build_item gfx/wr/webrender/src/scene_building.rs:1224
3 xul.dll webrender::scene_building::SceneBuilder::build_all gfx/wr/webrender/src/scene_building.rs:582
4 xul.dll webrender::scene_builder_thread::SceneBuilderThread::process_transaction gfx/wr/webrender/src/scene_builder_thread.rs:707
5 xul.dll webrender::scene_builder_thread::SceneBuilderThread::run gfx/wr/webrender/src/scene_builder_thread.rs:342
6 xul.dll std::sys_common::backtrace::__rust_begin_short_backtrace<closure-2,  ../4fb7144ed159f94491249e86d5bbd033b5d60550/src/libstd/sys_common/backtrace.rs:130
7 xul.dll core::ops::function::FnOnce::call_once<closure-0,  ../4fb7144ed159f94491249e86d5bbd033b5d60550/src/libcore/ops/function.rs:232
8 xul.dll alloc::boxed::{{impl}}::call_once< ../4fb7144ed159f94491249e86d5bbd033b5d60550/src/liballoc/boxed.rs:1017
9 xul.dll std::sys::windows::thread::{{impl}}::new::thread_start ../4fb7144ed159f94491249e86d5bbd033b5d60550//src/libstd/sys/windows/thread.rs:51

Reports started in Nightly build id 20200803094100. Maybe a regression from Bug 1656711?

Comment 1

[Timothy Nikkel (:tnikkel)]

Hmm, 9 crashes, 3 unique install times, all on win10 arm64. The code doesn't seem close to anything I changed in bug 1656711, but I'm not a webrender expert. Maybe Dzmitry can tell if it might be related to that bug?

Comment 2

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

Set release status flags based on info from the regressing bug 1656711

Comment 3

[Dzmitry Malyshau [:kvark]]

This is a rather strange error. Growing a vector there is never expected to run into a write access violation.
Something must be terribly wrong. It would help to look at the actual crash dump to see this, but I don't have that access.
Notably, the crash is inside DisplayItem::BackdropFilter handling, so may be it is related to the filtering changes? I.e. some sort of a driver bug on Win10 ARM that corrupts the state - just a wild guess. We could hide the GPU SVG filters under an option that is blocklisted on Win10 ARM in this case.

Comment 4

[Timothy Nikkel (:tnikkel)]

Okay, if it's possible bug 1656711 caused this I will just request backout of it and we can see if that fixes the problems or not. Much quicker way of making progress here then trying to wrangle a Windows arm machine and reproducing.

Comment 5

[Timothy Nikkel (:tnikkel)]

ni myself to check if the backout affected these crashes in a few days.

Comment 6

[Dzmitry Malyshau [:kvark]]

Crash volume isn't alarming yet, but adding to wr-triage to monitor it.

Comment 7

[Jens Stutte [:jstutte]]

Hi Timothy, it seems the backout of bug 1656711 helped here?

Comment 8

[Timothy Nikkel (:tnikkel)]

It seems like it yeah. I still suspect the crashes were unrelated and would have gone away even if we didn't back out. I'll try relanding the original bug and see if the crashes return.

Comment 9

[Timothy Nikkel (:tnikkel)]

I don't think the backout fixed this. Since I relanded the identical patch, so if we aren't seeing new crashes then it was unrelated.