Intermittent panic in ipc-channel code during tests

[jdm]

  │ assertion failed: self.fd == -1 (thread <unnamed>, at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ipc-channel-0.18.3/src/platform/unix/mod.rs:636)
  │    0: servoshell::backtrace::print
  │    1: servoshell::panic_hook::panic_hook
  │    2: std::panicking::rust_panic_with_hook
  │    3: std::panicking::begin_panic_handler::{{closure}}
  │    4: std::sys_common::backtrace::__rust_end_short_backtrace
  │    5: rust_begin_unwind
  │    6: core::panicking::panic_fmt
  │    7: core::panicking::panic
  │    8: core::ptr::drop_in_place<ipc_channel::ipc::IpcSelectionResult>
  │    9: <alloc::vec::into_iter::IntoIter<T,A> as core::ops::drop::Drop>::drop
  │   10: ipc_channel::router::Router::run
  │   11: std::sys_common::backtrace::__rust_begin_short_backtrace
  │   12: core::ops::function::FnOnce::call_once{{vtable.shim}}
  │   13: std::sys::pal::unix::thread::Thread::new::thread_start
  │   14: <unknown>
  └   15: <unknown>

[jdm]

Observed on CI in /css/css-masking/clip-path/clip-path-scaled-video.html

[mrobinson]

Is there any more context to the backtrace? I've been looking at the ipc-channel code and I think this happens when an IPC message is received, but not deserialized (perhaps deserialized improperly -- maybe due to something like https://github.com/servo/ipc-channel/issues/239).

[jdm]

There's no context—there was no other output from the test in question apart from the assertion failure and backtrace.