Intermittent crash in /workers/WorkerLocation-origin.sub.window.html

[jdm]

  ▶ CRASH [expected OK] /workers/WorkerLocation-origin.sub.window.html
  │ 
  │ VMware, Inc.
  │ softpipe
  │ 3.3 (Core Profile) Mesa 18.3.0-devel
  │ Layout thread disconnected.: "SendError(..)" (thread ScriptThread PipelineId { namespace_id: PipelineNamespaceId(1), index: PipelineIndex(1) }, at src/libcore/result.rs:999)
  │ stack backtrace:
  │    0:     0x7fb131f2be8d - backtrace::backtrace::trace::h8cf5e823e7b927c4
  │    1:     0x7fb131f2af72 - backtrace::capture::Backtrace::new::h57ad61985be7a0fb
  │    2:     0x7fb12f9f69a7 - servo::main::{{closure}}::h35768982dca81cb7
  │    3:     0x7fb132c05b49 - std::panicking::rust_panic_with_hook::h3efc9269f3975b4e
  │                         at src/libstd/panicking.rs:482
  │    4:     0x7fb132c055f1 - std::panicking::continue_panic_fmt::h0bb834397df0d69a
  │                         at src/libstd/panicking.rs:385
  │    5:     0x7fb132c054d5 - rust_begin_unwind
  │                         at src/libstd/panicking.rs:312
  │    6:     0x7fb132c2526c - core::panicking::panic_fmt::hce8ba5bc9a54c6f2
  │                         at src/libcore/panicking.rs:85
  │    7:     0x7fb1305c8149 - core::result::unwrap_failed::h9343c8b2b9049a14
  │    8:     0x7fb130004f94 - script::dom::window::Window::force_reflow::h8755c08dc1efa2b9
  │    9:     0x7fb130005710 - script::dom::window::Window::reflow::h3ade2e9258f01183
  │   10:     0x7fb13030e337 - script::dom::document::Document::finish_load::h1d51dc7e970bdb1b
  │   11:     0x7fb13009a3cf - script::dom::servoparser::ServoParser::do_parse_sync::h9828e4659df15389
  │   12:     0x7fb13059c792 - profile_traits::time::profile::h001f3c91848f4ca1
  │   13:     0x7fb130099a70 - _ZN6script3dom11servoparser11ServoParser10parse_sync17hffab3caf6a26fe09E.llvm.13894101220294098938
  │   14:     0x7fb13009fbdf - <script::dom::servoparser::ParserContext as net_traits::FetchResponseListener>::process_response_eof::h182b25e8d0d95369
  │   15:     0x7fb130542389 - script::script_thread::ScriptThread::handle_msg_from_constellation::h00b1d194fc128cea
  │   16:     0x7fb1305382c4 - _ZN6script13script_thread12ScriptThread11handle_msgs17h9e6b09790e3f4ea7E.llvm.3496197557420798891
  │   17:     0x7fb130533226 - script::script_thread::ScriptThread::start::h1484b91d67faaaad
  │   18:     0x7fb13059c2ce - profile_traits::mem::ProfilerChan::run_with_memory_reporting::ha803eda8ad327b82
  │   19:     0x7fb1306a9134 - std::sys_common::backtrace::__rust_begin_short_backtrace::h918092a582e94f30
  │   20:     0x7fb130beedd5 - _ZN3std9panicking3try7do_call17h1e1a4a7559b185dcE.llvm.9973224621453256981
  │   21:     0x7fb132c10859 - __rust_maybe_catch_panic
  │                         at src/libpanic_unwind/lib.rs:92
  │   22:     0x7fb1309107c7 - <F as alloc::boxed::FnBox<A>>::call_box::hcc4b12433ee715fb
  │   23:     0x7fb132c0fc0d - <alloc::boxed::Box<(dyn alloc::boxed::FnBox<A, Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$RP$$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::hf75cbe88140b524c
  │                         at /rustc/c0bbc3927e28c22edefe6a1353b5ecc95ea9a104/src/liballoc/boxed.rs:734
  │                          - std::sys_common::thread::start_thread::h9fb334ae2abaae80
  │                         at src/libstd/sys_common/thread.rs:14
  │                          - std::sys::unix::thread::Thread::new::thread_start::h772c7ae2e9d50018
  │                         at src/libstd/sys/unix/thread.rs:81
  │   24:     0x7fb12d640183 - start_thread
  │   25:     0x7fb12bf0703c - clone
  │   26:                0x0 - <unknown>
  │ [2019-01-08T14:22:26Z ERROR servo] Layout thread disconnected.: "SendError(..)"
  └ Pipeline failed in hard-fail mode.  Crashing!

[jdm]

@gterzian I remember seeing some comments from you about what it means when the layout thread is disconnected, but I can't recall where those comments were. This looks like another case where that would happen, but I'm surprised by the stack given the testcase source (https://github.com/web-platform-tests/wpt/blob/master/workers/WorkerLocation-origin.sub.window.js).

[gterzian]

The issue is opened at #22507, I guess the topic will expand as we discover similar cases...

It looks similar due to the crash on reflow inside a finish_load call, although I don't see how it ties back to the document being not "fully active" anymore in this case...

It might have something to do with the iframe being cross-origin(I think), because this occured before at #22559