Open Bug 1658425 Opened 4 years ago Updated 2 years ago

Crash in [@ webrender::scene_building::SceneBuilder::create_primitive<T>]

Categories

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

ARM64
Windows 10
defect

Tracking

()

Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- unaffected
firefox79 --- unaffected
firefox80 --- unaffected
firefox81 --- fix-optional

People

(Reporter: gsvelto, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: crash, regression)

Crash Data

This bug is for crash report bp-82801847-8e90-466a-a9db-930e10200808.

Top 10 frames of crashing thread:

0 xul.dll webrender::scene_building::SceneBuilder::create_primitive<webrender::prim_store::text_run::TextRun> gfx/wr/webrender/src/scene_building.rs:1335
1 xul.dll webrender::scene_building::SceneBuilder::build_all gfx/wr/webrender/src/scene_building.rs:582
2 xul.dll webrender::scene_building::SceneBuilder::build_all gfx/wr/webrender/src/scene_building.rs:582
3 xul.dll webrender::scene_builder_thread::SceneBuilderThread::process_transaction gfx/wr/webrender/src/scene_builder_thread.rs:707
4 xul.dll webrender::scene_builder_thread::SceneBuilderThread::run gfx/wr/webrender/src/scene_builder_thread.rs:342
5 xul.dll std::sys_common::backtrace::__rust_begin_short_backtrace<closure-2,  ../4fb7144ed159f94491249e86d5bbd033b5d60550/src/libstd/sys_common/backtrace.rs:130
6 xul.dll core::ops::function::FnOnce::call_once<closure-0,  ../4fb7144ed159f94491249e86d5bbd033b5d60550/src/libcore/ops/function.rs:232
7 xul.dll alloc::boxed::{{impl}}::call_once< ../4fb7144ed159f94491249e86d5bbd033b5d60550/src/liballoc/boxed.rs:1017
8 xul.dll std::sys::windows::thread::{{impl}}::new::thread_start ../4fb7144ed159f94491249e86d5bbd033b5d60550//src/libstd/sys/windows/thread.rs:51
9 mozglue.dll patched_BaseThreadInitThunk mozglue/dllservices/WindowsDllBlocklist.cpp:592

This seems to have started with buildid 20200807093158. All crashes are coming from Windows on ARM machines and they all report dual GPUs though I don't think they actually have them. When I checked on my ARM laptop it also reported two GPUs but one appeared to be the display controller, not an actual GPU.

We have several Windows ARM crashes in webrender code recently (bug 1657558 bug 1657964).

And if you look at the install times for all crashes for all three signatures the install times ranges never overlap. For example one has install times all on 2020-08-05 with times until 17:00. The next has install times on 2020-08-05 at 23:46 (so one install). And this bug is all 2020-08-07 or after.

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #3)

mozregression --good 20200806215439 --bad 20200807093158

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=95cbd137913873b3e3dddda4b4d895ce28e04048&tochange=cc8993c8140a06f97b7f91208e608c01c350961b

Nothing really in there webrender-y.

@Jim: Could you take a look at this, crash rate seems low, so might be fixed.

Flags: needinfo?(jimb)
Severity: -- → S3
Priority: -- → P3

I think this also has occurred a few times on Linux, for example:
https://crash-stats.mozilla.org/report/index/785b9462-825d-4627-92e6-265c30200822

Flags: needinfo?(jimb)

(In reply to Timothy Nikkel (:tnikkel) from comment #4)

Nothing really in there webrender-y.

What about these?

f1f10f791e991b44a2abbb3db989f9c3aa4f72e5	Jeff Gilbert — Bug 1656034 - Support multiple EglDisplays per GLLibraryEGL. r=lsalzman,sotaro,stransky
d1268fb4ae8ae803af87ca0c127e292bf6a8f930	Matt Woodrow — Bug 1657523 - Compute the scale from size for async image pipelines in the compositor process, so that we get the size matching the current texture. r=aosmond
c14317d9e192d1298ac8a95cf297e4f0dc5cc3bd	Jamie Nicol — Bug 1656554 - Enable webrender on Adreno 5xx GPUs excluding 505 and 506. r=ktaeleman,geckoview-reviewers,snorp

Given this:

All crashes are coming from Windows on ARM machines and they all report dual GPUs though I don't think they actually have them.

I wonder whether it's related to bug 1656034.

Jeff, Jamie, does this look like it could be related to that work?

Flags: needinfo?(jnicol)
Flags: needinfo?(jgilbert)

I needinfo'd Jamie, too, because of the ARM angle. Although it also has occurred on Linux x86_64 a few times, so it's unclear.

The source line it's crashing on makes no sense to me.

I don't see how my commit in that range could have caused this. The device does have an Adreno (600), but that change only affects Android devices.

The source line it's crashing on makes no sense to me either. But something is going seriously wrong, the url is chrome://gfxsanity/content/sanitytest.html, and the GraphicsCriticalError is full of Receive IPC close with reason=AbnormalShutdown.

Flags: needinfo?(jnicol)

This is with WR prefs on, which may be a user testing our WR ahead of normal supported rollout.
It does sound like it might have to do with bug 1656034.
I don't have this particular device, but I do have a aarch64 windows machine I can test. Given low volume this doesn't seem severe or urgent, but I'll check my machine.

Assignee: nobody → jgilbert
Flags: needinfo?(jgilbert)
Regressed by: 1656034
Has Regression Range: --- → yes
Severity: S3 → S4

Nightly seems fine on my Win10+Adreno630, with WR enabled via pref.
chrome://gfxsanity/content/sanitytest.html runs manually (via url) without error.
Happy to try more things, but WORKSFORME so far.

NB: This machine also claims to have two GPUs, just like the machines in the crash reports.

I guess we can keep an eye if this spikes, but I can't move this forward further for the moment.

Assignee: jgilbert → nobody
You need to log in before you can comment on or make changes to this bug.