Jesse Schwartzentruber (:truber) Reporter
	Description • 6 years ago

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

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 1 • 6 years ago

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.

	Jesse Schwartzentruber (:truber) Reporter
	Comment 2 • 6 years ago

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

	Jeff Muizelaar [:jrmuizel]
	Comment 3 • 6 years ago

Kats, is there any reason we'd need to deal with this for the MVP?

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 4 • 6 years ago

I don't see any reason, no.