Open Bug 1653649 Opened 2 months ago Updated 9 hours ago

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

Categories

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

Unspecified
Windows 10
defect

Tracking

()

ASSIGNED
Tracking Status
firefox80 --- affected

People

(Reporter: kashav, Assigned: nical, NeedInfo)

References

(Blocks 2 open bugs)

Details

(Keywords: crash, leave-open)

Crash Data

Attachments

(1 file)

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.

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)

Nical, Kats - any suggestions for this one?

Flags: needinfo?(nical.bugzilla)
Flags: needinfo?(kats)
Blocks: wr-80
Severity: -- → S3
Priority: -- → P3

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

Flags: needinfo?(kats)

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?

Flags: needinfo?(nical.bugzilla) → needinfo?(dmalyshau)

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

Assignee: nobody → nical.bugzilla
Status: NEW → ASSIGNED
Keywords: leave-open
Pushed by nsilva@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d72fa7f1c347
Add window size sanity check at the API level. r=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.

Flags: needinfo?(dmalyshau)

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

Flags: needinfo?(nical.bugzilla)

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.

Flags: needinfo?(nical.bugzilla)
No longer blocks: wr-80
Blocks: wr-81

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

Crash Signature: [@ webrender::render_task::render_task_sanity_check] → [@ webrender::render_task::render_task_sanity_check] [@ webrender_api::api::window_size_sanity_check ]

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

Flags: needinfo?(nical.bugzilla)
No longer blocks: wr-81
No longer blocks: gfx-82
You need to log in before you can comment on or make changes to this bug.