Closed Bug 1470521 Opened 7 years ago Closed 5 years ago

thread 'WRRenderBackend#1' panicked at 'assertion failed: sticky_offset.x + info.previously_applied_offset.x >= 0.0', gfx/webrender/src/clip_scroll_node.rs:577:13

Categories

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

defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr68 --- wontfix
firefox62 --- wontfix
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- wontfix
firefox71 --- wontfix
firefox72 --- wontfix
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- fixed

People

(Reporter: truber, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: assertion, testcase)

Attachments

(1 file, 1 obsolete file)

Attached file testcase.html (obsolete) —
The attached testcase causes a panic in m-c 20180622-6b6f3f6ecf14 with pref("gfx.webrender.all", true) thread 'WRRenderBackend#1' panicked at 'assertion failed: sticky_offset.x + info.previously_applied_offset.x >= 0.0', gfx/webrender/src/clip_scroll_node.rs:577:13 #0: mozalloc_abort at memory/mozalloc/mozalloc_abort.cpp:34 #1: abort at memory/mozalloc/mozalloc_abort.cpp:81 #2: panic_abort::__rust_start_panic at src/libpanic_abort/lib.rs:59 #3: std::panicking::rust_panic at src/libstd/panicking.rs:608 #4: std::panicking::rust_panic_with_hook at src/libstd/panicking.rs:593 #5: std::panicking::begin_panic at src/libstd/panicking.rs:538 #6: webrender::clip_scroll_node::ClipScrollNode::update at gfx/webrender/src/clip_scroll_node.rs:0 #7: webrender::clip_scroll_tree::ClipScrollTree::update_node at gfx/webrender/src/clip_scroll_tree.rs:283 #8: webrender::clip_scroll_tree::ClipScrollTree::update_node at gfx/webrender/src/clip_scroll_tree.rs:305 #9: webrender::clip_scroll_tree::ClipScrollTree::update_node at gfx/webrender/src/clip_scroll_tree.rs:305 #10: webrender::clip_scroll_tree::ClipScrollTree::update_node at gfx/webrender/src/clip_scroll_tree.rs:305 #11: webrender::clip_scroll_tree::ClipScrollTree::update_node at gfx/webrender/src/clip_scroll_tree.rs:305 #12: webrender::clip_scroll_tree::ClipScrollTree::update_node at gfx/webrender/src/clip_scroll_tree.rs:305 #13: webrender::clip_scroll_tree::ClipScrollTree::update_node at gfx/webrender/src/clip_scroll_tree.rs:305 #14: webrender::clip_scroll_tree::ClipScrollTree::update_node at gfx/webrender/src/clip_scroll_tree.rs:305 #15: webrender::clip_scroll_tree::ClipScrollTree::update_node at gfx/webrender/src/clip_scroll_tree.rs:305 #16: webrender::clip_scroll_tree::ClipScrollTree::update_node at gfx/webrender/src/clip_scroll_tree.rs:305 #17: webrender::clip_scroll_tree::ClipScrollTree::update_tree at gfx/webrender/src/clip_scroll_tree.rs:244 #18: webrender::render_backend::Document::render at gfx/webrender/src/frame_builder.rs:310 #19: webrender::render_backend::RenderBackend::update_document at gfx/webrender/src/render_backend.rs:1075 #20: webrender::render_backend::RenderBackend::run at gfx/webrender/src/render_backend.rs:759 #21: std::sys_common::backtrace::__rust_begin_short_backtrace at gfx/webrender/src/renderer.rs:1743 #22: std::panicking::try::do_call at src/libstd/thread/mod.rs:406 #23: panic_abort::__rust_maybe_catch_panic at src/libpanic_abort/lib.rs:38 #24: _..boxed..FnBox1101GT$::call_box at src/libstd/panicking.rs:459 #25: std::sys_common::thread::start_thread at src/liballoc/boxed.rs:825 #26: std::sys::unix::thread::Thread::new::thread_start at src/libstd/sys/unix/thread.rs:90
Flags: in-testsuite?
Spent some time today looking into this. Pretty sure that this is (a) a gecko side problem (b) only happens when the root document element is made position:sticky, which is basically never in practice. I didn't spend enough time to drill down to the root cause but it seems to be a mismatch between what StickyScrollContainer::ComputeStickyLimits is producing as output and how the CreateWebRenderCommands code is interpreting it. Also given that it's a debug assertion failure which won't affect users I'm downgrading this from P1.
Priority: P1 → P2
Blocks: wr-fuzz
Attached file testcase2.html
I couldn't reproduce with the original testcase, but this is still panicking in m-c 20180912-2a59b432d2bd. I have testcases with sticky_offset.x (panic on line 417) and sticky_offset.y, I'm assuming it's the same problem. thread 'WRRenderBackend#1' panicked at 'assertion failed: sticky_offset.y + info.previously_applied_offset.y >= 0.0', gfx/webrender/src/spatial_node.rs:383:13 #0: mozalloc_abort at memory/mozalloc/mozalloc_abort.cpp:35 #1: abort at memory/mozalloc/mozalloc_abort.cpp:82 #2: panic_abort::__rust_start_panic::abort at src/libpanic_abort/lib.rs:61 #3: __rust_start_panic at src/libpanic_abort/lib.rs:56 #4: rust_panic at src/libstd/panicking.rs:559 #5: std::panicking::rust_panic_with_hook at src/libstd/panicking.rs:531 #6: std::panicking::begin_panic at src/libstd/panicking.rs:445 #7: webrender::spatial_node::SpatialNode::update at gfx/webrender/src/spatial_node.rs:0 #8: webrender::clip_scroll_tree::ClipScrollTree::update_node at gfx/webrender/src/clip_scroll_tree.rs:307 #9: webrender::clip_scroll_tree::ClipScrollTree::update_node at gfx/webrender/src/clip_scroll_tree.rs:319 #10: webrender::clip_scroll_tree::ClipScrollTree::update_node at gfx/webrender/src/clip_scroll_tree.rs:319 #11: webrender::clip_scroll_tree::ClipScrollTree::update_node at gfx/webrender/src/clip_scroll_tree.rs:319 #12: webrender::clip_scroll_tree::ClipScrollTree::update_node at gfx/webrender/src/clip_scroll_tree.rs:319 #13: webrender::clip_scroll_tree::ClipScrollTree::update_node at gfx/webrender/src/clip_scroll_tree.rs:319 #14: webrender::clip_scroll_tree::ClipScrollTree::update_tree at gfx/webrender/src/clip_scroll_tree.rs:281 #15: webrender::frame_builder::FrameBuilder::build at gfx/webrender/src/frame_builder.rs:342 #16: webrender::render_backend::Document::build_frame at gfx/webrender/src/render_backend.rs:237 #17: webrender::render_backend::RenderBackend::update_document at gfx/webrender/src/render_backend.rs:944 #18: webrender::render_backend::RenderBackend::run at gfx/webrender/src/render_backend.rs:573 #19: std::sys_common::backtrace::__rust_begin_short_backtrace at gfx/webrender/src/renderer.rs:1755 #20: std::panicking::try::do_call at src/libstd/thread/mod.rs:409 #21: __rust_maybe_catch_panic at src/libpanic_abort/lib.rs:39 #22: <F as alloc::boxed::FnBox<A>>::call_box at src/libstd/panicking.rs:289 #23: std::sys_common::thread::start_thread at src/liballoc/boxed.rs:650 #24: std::sys::unix::thread::Thread::new::thread_start at src/libstd/sys/unix/thread.rs:90
Attachment #8987152 - Attachment is obsolete: true
Priority: P2 → P3
Kats, is there any reason we'd need to deal with this for the MVP?
Blocks: stage-wr-next
No longer blocks: stage-wr-trains
Flags: needinfo?(kats)
I don't see any reason, no.
Flags: needinfo?(kats)

Fixed by removal of the assertion in bug 1628484.

Status: NEW → RESOLVED
Closed: 5 years ago
Depends on: 1628484
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: