Open Bug 1470521 Opened 2 years ago Updated 3 months 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

()

Tracking Status
firefox-esr68 --- affected
firefox62 --- wontfix
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- wontfix
firefox71 --- affected
firefox72 --- affected

People

(Reporter: truber, Unassigned)

References

(Blocks 3 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?
Priority: -- → P1
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)
You need to log in before you can comment on or make changes to this bug.