Crash in [@ wr_transaction_set_document_view]
Categories
(Core :: Graphics, defect)
Tracking
()
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
Comment 1•4 years ago
|
||
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.
Assignee | ||
Comment 2•4 years ago
|
||
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.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 3•4 years ago
|
||
As of Dec 19 (fenix 84?) the crash rate is basically zero
https://crash-stats.mozilla.org/signature/?signature=wr_transaction_set_document_view&date=%3E%3D2020-09-21T16%3A22%3A00.000Z&date=%3C2021-03-21T16%3A22%3A00.000Z#graphs
Updated•4 years ago
|
Updated•4 years ago
|
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.
Assignee | ||
Comment 5•3 years ago
|
||
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.
Comment 6•3 years ago
|
||
(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.
Description
•