1653649 - Crash in [@ webrender::render_task::render_task_sanity_check]

Status: RESOLVED FIXED

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

Description

[u608768]

This bug is for crash report bp-95a82e4c-e3a7-4a22-9a22-8b7120200717.

Top 10 frames of crashing thread:

0 xul.dll RustMozCrash mozglue/static/rust/wrappers.cpp:16
1 xul.dll mozglue_static::panic_hook mozglue/static/rust/lib.rs:89
2 xul.dll core::ops::function::Fn::call<fn ../4fb7144ed159f94491249e86d5bbd033b5d60550/src/libcore/ops/function.rs:232
3 xul.dll std::panicking::rust_panic_with_hook ../4fb7144ed159f94491249e86d5bbd033b5d60550//src/libstd/panicking.rs:474
4 xul.dll std::panicking::begin_panic<str*> ../4fb7144ed159f94491249e86d5bbd033b5d60550/src/libstd/panicking.rs:397
5 xul.dll webrender::render_task::render_task_sanity_check gfx/wr/webrender/src/render_task.rs:38
6 xul.dll static webrender::render_task::RenderTask::new_picture gfx/wr/webrender/src/render_task.rs:415
7 xul.dll webrender::frame_builder::FrameBuilder::build gfx/wr/webrender/src/frame_builder.rs:546
8 xul.dll webrender::render_backend::Document::build_frame gfx/wr/webrender/src/render_backend.rs:649
9 xul.dll webrender::render_backend::RenderBackend::update_document gfx/wr/webrender/src/render_backend.rs:1609

Started in build 20200716212737. Regression window: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c8e9ecbc6236ea4cf1aa5063f20583e1f574f2b9&tochange=a35461d1fc07e6e855d064453363a46d32bb5a3d

Pretty high volume, but only 2 installations across 2 builds, so it might be a single device.

Comment 1

[Andrew McCreight [:mccr8]]

The graphics critical errors are things like:
|[G0][GFX1-]: Attempting to create a render task of size 39414x11 (t=339.771)
|[G0][GFX1-]: Attempting to create a render task of size 19702x11 (t=34212.6)

Comment 2

[Jessie [:jbonisteel] pls NI]

Nical, Kats - any suggestions for this one?

Comment 3

[Kartikaya Gupta (email:[e-mail])]

I'm not particularly familiar with what goes into determining render task sizes. Leaving this one for nical.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

(In reply to :kashav from comment #0)

Started in build 20200716212737. Regression window: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c8e9ecbc6236ea4cf1aa5063f20583e1f574f2b9&tochange=a35461d1fc07e6e855d064453363a46d32bb5a3d

Could be a regression from bug 1647918, maybe.

Comment 5

[Nicolas Silva [:nical]]

It indeed looks like all windows crashes are coming from the same device.

The backtrace looks suspiciously like the document main picture render task, like we are trying to create an enormous window. I wonder if we are getting some garbage widget size. We should get into a habit of validating things in the API more, it's harder to untangle when we hit an assert later in another thread.

Most of the crashes happened in about:newtab/about:blank/about:home.

It's not obvious to me that the clipping changes in bug 1647918 could have caused us to let an enormous picture render task to be created, but I could have missed something. Dzmitry can you confirm?

Comment 6

[Nicolas Silva [:nical]]

Attachment: Bug 1653649 - Add window size sanity check at the API level. r=kvark

Better to catch these in the API than later on some other thread.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d72fa7f1c347
Add window size sanity check at the API level. r=kvark

Comment 8

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/d72fa7f1c347

Comment 9

[Dzmitry Malyshau [:kvark]]

The changes in bug 1647918 where making us handling the clipped out items earlier. So effectively they reduced the pipeline for some cases, not extended it. I don't see how they would affect this issue.

Comment 10

[Kris Taeleman (:ktaeleman)]

@nical: Could you see if your extra sanity check callstack is present in crash-stats?

Comment 11

[Nicolas Silva [:nical]]

There are a few crashes on android with unreasonable sizes in set_document_view: https://crash-stats.mozilla.org/signature/?product=Fenix&signature=wr_transaction_set_document_view&date=%3E%3D2020-07-24T08%3A08%3A00.000Z&date=%3C2020-07-31T08%3A08%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=1#reports

There's also one crash on windows: https://crash-stats.mozilla.org/report/index/cbec8b3a-f976-4bdf-a1ef-f6b430200723

It's not a lot of crashes and the volume of the original signature has gone down before the patch landed, though, so it's hard to get definitive conclusions. The latest build ID with the original signature I could find is from 18/07/2020 which is a few days before this patch landed which would lean towards this indeed revolving around nonsensical window sizes.

Comment 12

[Andrew McCreight [:mccr8]]

There are some crashes in a recent Linux nightly with cras reasons like "Attempting to create a 36033x32778 window/document"

bp-bdf1a694-6fdd-4895-a893-752f10200820

Comment 13

[Kris Taeleman (:ktaeleman)]

@Nical: Looks like there are more reports coming in.

Comment 14

[Nicolas Silva [:nical]]

Attachment: Bug 1653649 - Limit widget size to 16k. r=jrmuizel

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f77f5a13f8c2
Limit widget size to 16k. r=jrmuizel

Comment 16

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/f77f5a13f8c2