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)
Core
Graphics: WebRender
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)
117 bytes,
text/html
|
Details |
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?
Updated•7 years ago
|
Blocks: stage-wr-trains
Priority: -- → P1
Comment 1•7 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.
Priority: P1 → P2
Reporter | ||
Comment 2•7 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
Attachment #8987152 -
Attachment is obsolete: true
Updated•7 years ago
|
Priority: P2 → P3
Comment 3•7 years ago
|
||
Kats, is there any reason we'd need to deal with this for the MVP?
Flags: needinfo?(kats)
Updated•7 years ago
|
Updated•7 years ago
|
Updated•6 years ago
|
Comment 5•6 years ago
|
||
A Pernosco session is available here: https://pernos.co/debug/aPcgARad2hLucJ-kgpcJ_Q/index.html
The session will expire in 7 days.
status-firefox70:
--- → wontfix
status-firefox71:
--- → affected
status-firefox72:
--- → affected
status-firefox-esr68:
--- → affected
Comment 6•5 years ago
|
||
Fixed by removal of the assertion in bug 1628484.
Updated•5 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•