Closed Bug 1668555 Opened 4 years ago Closed 4 years ago

Crash in [@ wr_transaction_set_document_view]

Categories

(Core :: Graphics, defect)

ARM
Android
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox81 --- wontfix
firefox82 --- wontfix
firefox83 --- wontfix

People

(Reporter: kbrosnan, Assigned: jnicol)

References

(Blocks 1 open bug)

Details

(Keywords: crash)

Crash Data

Crash report: https://crash-stats.mozilla.org/report/index/168a82ed-25ed-4724-8168-0b4170201001

Reason: SIGSEGV /SEGV_MAPERR

Top 10 frames of crashing thread:

0 libxul.so RustMozCrash mozglue/static/rust/wrappers.cpp:17
1 libxul.so mozglue_static::panic_hook mozglue/static/rust/lib.rs:89
2 libxul.so core::ops::function::Fn::call src/libcore/ops/function.rs:72
3 libxul.so std::panicking::rust_panic_with_hook src/libstd/panicking.rs:474
4 libxul.so rust_begin_unwind src/libstd/panicking.rs:378
5 libxul.so std::panicking::begin_panic_fmt src/libstd/panicking.rs:332
6 libxul.so wr_transaction_set_document_view gfx/webrender_bindings/src/bindings.rs:1788
7 libxul.so mozilla::wr::TransactionBuilder::SetDocumentView gfx/webrender_bindings/WebRenderAPI.cpp:282
8 libxul.so mozilla::layers::WebRenderBridgeParent::SetDisplayList gfx/layers/wr/WebRenderBridgeParent.cpp:1041
9 libxul.so mozilla::layers::WebRenderBridgeParent::ProcessDisplayListData gfx/layers/wr/WebRenderBridgeParent.cpp:1096

Crash rate has spiked quite a bit recently. Perhaps when 81 went to release on Fenix?

Top panic reasons are all variants of:
Attempting to create a 1080x16777069 window/document

No URL data was submitted with the reports.

Only similar bug with that in the proto signature is bug 1653649, which seems more in the realm of sanity.

Blocks: gfx-83
Severity: -- → S2
Flags: needinfo?(jnicol)
Hardware: Unspecified → ARM

Yeah, presumably the spike comes from the increase in android devices running webrender in 81.

I know that there is a race condition between java updating the widget's window size, and the compositor reading the widget's window size, which could perhaps be responsible for the garbage value. We send the new size to the Compositor thread in CompositorBridgeParent::ResumeCompositionAndResize() which then gets
saved in the layers compositor, perhaps for this reason. Maybe we should also save the size in WebRenderBridgeParent and use it rather than querying the widget.

And if that doesn't work I guess we should keep moving the assertion further back through the code until we find where it comes from.

Assignee: nobody → jnicol
Blocks: gfx-triage
No longer blocks: gfx-83
Blocks: wr-stability
No longer blocks: gfx-triage
Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(jmathies)
Resolution: --- → FIXED
Flags: needinfo?(jnicol)
Resolution: FIXED → WORKSFORME

I get this reproducibly on Linux x86_64 Wayland when I try to open the menu for a bookmark folder containing 34 items on a 1920x1080 display. If I move the window to a 1920x1080 display, the crash does not occur.

If you could file a new bug that would be great! This one was for an Android issue, even if the crash signature matches the underlying cause is likely different. also more people will see it that way! Thanks.

(In reply to matias from comment #4)

I get this reproducibly on Linux x86_64 Wayland when I try to open the menu for a bookmark folder containing 34 items on a 1920x1080 display. If I move the window to a 1920x1080 display, the crash does not occur.

Wayland is probably bug 1695591.

You need to log in before you can comment on or make changes to this bug.