Closed Bug 1657558 Opened 4 years ago Closed 4 years ago

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


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

Windows 10



81 Branch
Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- unaffected
firefox79 --- unaffected
firefox80 --- unaffected
firefox81 --- fixed


(Reporter: sg, Unassigned)


(Blocks 1 open bug, Regression)


(Keywords: crash, regression)

Crash Data

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/
1 xul.dll webrender::scene_building::SceneBuilder::build_item gfx/wr/webrender/src/
2 xul.dll webrender::scene_building::SceneBuilder::build_item gfx/wr/webrender/src/
3 xul.dll webrender::scene_building::SceneBuilder::build_all gfx/wr/webrender/src/
4 xul.dll webrender::scene_builder_thread::SceneBuilderThread::process_transaction gfx/wr/webrender/src/
5 xul.dll webrender::scene_builder_thread::SceneBuilderThread::run gfx/wr/webrender/src/
6 xul.dll std::sys_common::backtrace::__rust_begin_short_backtrace<closure-2,  ../4fb7144ed159f94491249e86d5bbd033b5d60550/src/libstd/sys_common/
7 xul.dll core::ops::function::FnOnce::call_once<closure-0,  ../4fb7144ed159f94491249e86d5bbd033b5d60550/src/libcore/ops/
8 xul.dll alloc::boxed::{{impl}}::call_once< ../4fb7144ed159f94491249e86d5bbd033b5d60550/src/liballoc/
9 xul.dll std::sys::windows::thread::{{impl}}::new::thread_start ../4fb7144ed159f94491249e86d5bbd033b5d60550//src/libstd/sys/windows/

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

Flags: needinfo?(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?

Flags: needinfo?(tnikkel) → needinfo?(dmalyshau)

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

Blocks: wr-stability

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.

Flags: needinfo?(dmalyshau)

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.

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

Flags: needinfo?(tnikkel)

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

Severity: -- → S3
Depends on: gfx-triage
Priority: -- → P3

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

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.

Flags: needinfo?(tnikkel)
Closed: 4 years ago
Resolution: --- → FIXED
Assignee: nobody → tnikkel
Target Milestone: --- → 81 Branch

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.

Assignee: tnikkel → nobody
No longer depends on: gfx-triage
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.