Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

internal error: entered unreachable code: Tried to use WebRender SpatialId before it was defined. #19281

Closed
mateon1 opened this issue Nov 18, 2017 · 2 comments

Comments

@mateon1
Copy link
Contributor

@mateon1 mateon1 commented Nov 18, 2017

Found with modified domato.

Testcase (happens with textarea as well):

<style>
html{overflow:auto;width:0;transform:translate(0)}
html,input{text-overflow:ellipsis}
</style>
<input>
VMware, Inc.
softpipe
3.3 (Core Profile) Mesa 17.3.0-devel
internal error: entered unreachable code: Tried to use WebRender ClipId before it was defined. (thread LayoutThread PipelineId { namespace_id: PipelineNamespaceId(0), index: PipelineIndex(NonZero(NonZero(1))) }, at components/layout/webrender_helpers.rs:276)
stack backtrace:
   0:     0x557f0e3661b4 - backtrace::backtrace::libunwind::trace
                        at .cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.2/src/backtrace/libunwind.rs:53
                         - backtrace::backtrace::trace<closure>
                        at .cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.2/src/backtrace/mod.rs:42
   1:     0x557f0e35b50f - backtrace::capture::{{impl}}::new
                        at .cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.2/src/capture.rs:64
   2:     0x557f0d8645de - servo::main::{{closure}}
                        at ports/servo/main.rs:130
   3:     0x557f140a9556 - std::panicking::rust_panic_with_hook
                        at /checkout/src/libstd/panicking.rs:578
   4:     0x557f140a93e4 - std::panicking::begin_panic<alloc::string::String>
                        at /checkout/src/libstd/panicking.rs:538
   5:     0x557f140a92e9 - std::panicking::begin_panic_fmt
                        at /checkout/src/libstd/panicking.rs:522
   6:     0x557f11c46478 - layout::webrender_helpers::{{impl}}::convert_to_webrender::{{closure}}
                        at components/layout/webrender_helpers.rs:276
   7:     0x557f11b5c20e - layout::webrender_helpers::{{impl}}::convert_to_webrender
                        at components/layout/webrender_helpers.rs:281
   8:     0x557f11b5be77 - layout::webrender_helpers::{{impl}}::convert_to_webrender
                        at components/layout/webrender_helpers.rs:240
   9:     0x557f0f0bb070 - layout_thread::{{impl}}::compute_abs_pos_and_build_display_list::{{closure}}
                        at components/layout_thread/lib.rs:1032
  10:     0x557f0ef83a51 - profile_traits::time::profile<(),closure>
                        at /shared/dev/rust/servo/components/profile_traits/time.rs:125
  11:     0x557f0f0ba2d5 - layout_thread::{{impl}}::compute_abs_pos_and_build_display_list
                        at components/layout_thread/lib.rs:961
  12:     0x557f0f0c1c2e - layout_thread::{{impl}}::perform_post_main_layout_passes
                        at components/layout_thread/lib.rs:1613
  13:     0x557f0f0c1504 - layout_thread::{{impl}}::perform_post_style_recalc_layout_passes
                        at components/layout_thread/lib.rs:1597
  14:     0x557f0f0be2ee - layout_thread::{{impl}}::handle_reflow
                        at components/layout_thread/lib.rs:1315
  15:     0x557f0f0b82bd - layout_thread::{{impl}}::handle_request_helper::{{closure}}
                        at components/layout_thread/lib.rs:698
  16:     0x557f0ef836a3 - profile_traits::time::profile<(),closure>
                        at /shared/dev/rust/servo/components/profile_traits/time.rs:125
  17:     0x557f0f0b6fcf - layout_thread::{{impl}}::handle_request_helper
                        at components/layout_thread/lib.rs:695
  18:     0x557f0f0b5e1b - layout_thread::{{impl}}::handle_request
                        at components/layout_thread/lib.rs:641
  19:     0x557f0f0b5133 - layout_thread::{{impl}}::start
                        at components/layout_thread/lib.rs:554
  20:     0x557f0f0b1ef9 - layout_thread::{{impl}}::create::{{closure}}::{{closure}}
                        at components/layout_thread/lib.rs:314
  21:     0x557f0ef81a79 - profile_traits::mem::{{impl}}::run_with_memory_reporting<closure,fn(profile_traits::mem::ReportsChan) -> script_layout_interface::message::Msg,script_layout_interface::message::Msg,std::sync::mpsc::Sender<script_layout_interface::message::Msg>>
                        at /shared/dev/rust/servo/components/profile_traits/mem.rs:63
  22:     0x557f0f0b2493 - layout_thread::{{impl}}::create::{{closure}}
                        at components/layout_thread/lib.rs:313
  23:     0x557f0f2f763a - std::sys_common::backtrace::__rust_begin_short_backtrace<closure,()>
                        at /checkout/src/libstd/sys_common/backtrace.rs:134
  24:     0x557f0efc95d3 - std::thread::{{impl}}::spawn::{{closure}}::{{closure}}<closure,()>
                        at /checkout/src/libstd/thread/mod.rs:400
  25:     0x557f0f2c039a - std::panic::{{impl}}::call_once<(),closure>
                        at /checkout/src/libstd/panic.rs:296
  26:     0x557f0f22ccc2 - std::panicking::try::do_call<std::panic::AssertUnwindSafe<closure>,()>
                        at /checkout/src/libstd/panicking.rs:480
  27:     0x557f140b069c - panic_unwind::__rust_maybe_catch_panic
                        at /checkout/src/libpanic_unwind/lib.rs:99
  28:     0x557f0f22c2fc - std::panicking::try<(),std::panic::AssertUnwindSafe<closure>>
                        at /checkout/src/libstd/panicking.rs:459
  29:     0x557f0f2f9635 - std::panic::catch_unwind<std::panic::AssertUnwindSafe<closure>,()>
                        at /checkout/src/libstd/panic.rs:361
  30:     0x557f0efc93fb - std::thread::{{impl}}::spawn::{{closure}}<closure,()>
                        at /checkout/src/libstd/thread/mod.rs:399
  31:     0x557f0f03b4f3 - alloc::boxed::{{impl}}::call_box<(),closure>
                        at /checkout/src/liballoc/boxed.rs:762
  32:     0x557f140a826b - alloc::boxed::{{impl}}::call_once<(),()>
                        at /checkout/src/liballoc/boxed.rs:772
                         - std::sys_common::thread::start_thread
                        at /checkout/src/libstd/sys_common/thread.rs:24
                         - std::sys::imp::thread::{{impl}}::new::thread_start
                        at /checkout/src/libstd/sys/unix/thread.rs:90
  33:     0x7fd3b54db493 - start_thread
  34:     0x7fd3b4e00abe - __clone
  35:                0x0 - <unknown>
ERROR:servo: internal error: entered unreachable code: Tried to use WebRender ClipId before it was defined.
Pipeline failed in hard-fail mode.  Crashing!
thread panicked while processing panic. aborting.
Servo exited with return value 1
@asajeffrey
Copy link
Member

@asajeffrey asajeffrey commented Sep 7, 2018

This is happening on the archived version of yahoo.com, as seen at https://servo.org/dashboards/

@jdm jdm changed the title internal error: entered unreachable code: Tried to use WebRender ClipId before it was defined. internal error: entered unreachable code: Tried to use WebRender SpatialId before it was defined. Feb 5, 2019
@jdm
Copy link
Member

@jdm jdm commented Feb 5, 2019

Encountered on http://www.naver.com when trying to reproduce #18687.

bors-servo added a commit that referenced this issue Dec 6, 2019
Fix "Tried to use SpatialId before it was defined" layout panic

In the case where an element uses `text-overflow: ellipsis` and causes overflow, we create a TruncatedFragment that wraps the original overflowing fragment. When collecting stacking contexts for the truncated fragment, #18510 addressed the case where the wrapped fragment wouldn't be processed, but neglected the case where that fragment ends up creating a new stacking context. When that happens, the TruncatedFragment would be stuck with the updated scrolling/clipping information based on the new stacking context, but it would be a child of the parent stacking context. Since the new scrolling/clipping nodes do not exist in the display list until the new stacking context display item is created, this led to the observed panic.

---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix #24895 and #19281 and #22826.
- [x] There are tests for these changes
bors-servo added a commit that referenced this issue Dec 6, 2019
Fix "Tried to use SpatialId before it was defined" layout panic

In the case where an element uses `text-overflow: ellipsis` and causes overflow, we create a TruncatedFragment that wraps the original overflowing fragment. When collecting stacking contexts for the truncated fragment, #18510 addressed the case where the wrapped fragment wouldn't be processed, but neglected the case where that fragment ends up creating a new stacking context. When that happens, the TruncatedFragment would be stuck with the updated scrolling/clipping information based on the new stacking context, but it would be a child of the parent stacking context. Since the new scrolling/clipping nodes do not exist in the display list until the new stacking context display item is created, this led to the observed panic.

---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix #24895 and #19281 and #22826.
- [x] There are tests for these changes
bors-servo added a commit that referenced this issue Dec 9, 2019
Fix "Tried to use SpatialId before it was defined" layout panic

In the case where an element uses `text-overflow: ellipsis` and causes overflow, we create a TruncatedFragment that wraps the original overflowing fragment. When collecting stacking contexts for the truncated fragment, #18510 addressed the case where the wrapped fragment wouldn't be processed, but neglected the case where that fragment ends up creating a new stacking context. When that happens, the TruncatedFragment would be stuck with the updated scrolling/clipping information based on the new stacking context, but it would be a child of the parent stacking context. Since the new scrolling/clipping nodes do not exist in the display list until the new stacking context display item is created, this led to the observed panic.

---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix #24895 and fix #19281 and fix #22826.
- [x] There are tests for these changes
@bors-servo bors-servo closed this in e8d677a Dec 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants
You can’t perform that action at this time.