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

Intermittent CRASH in /streams/readable-streams/crashtests/strategy-worker-terminate.html #30124

Closed
mukilan opened this issue Aug 18, 2023 · 1 comment · Fixed by #30896
Closed
Labels
A-content/script Related to the script thread I-crash No impact; the issue is one of maintainability or tidiness. I-intermittent Problem reproduces intermittently. L-javascript Javascript is required

Comments

@mukilan
Copy link
Member

mukilan commented Aug 18, 2023

This happens in layout 2020

Shutting down the Constellation after generating an output file or exit flag specified
assertion failed: `(left == right)`
  left: `2`,
 right: `1`: This runtime still has live children. (thread Script(1,1), at /home/mukilan/.cargo/git/checkouts/mozjs-fa11ffc7d4f1cc2d/8216870/rust-mozjs/src/rust.rs:411)
   0: servo::backtrace::print
   1: servo::main::{{closure}}
   2: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call
             at /rustc/dc1d9d50fba2f6a1ccab8748a0050cde38253f60/library/alloc/src/boxed.rs:2002:9
      std::panicking::rust_panic_with_hook
             at /rustc/dc1d9d50fba2f6a1ccab8748a0050cde38253f60/library/std/src/panicking.rs:692:13
   3: std::panicking::begin_panic_handler::{{closure}}
             at /rustc/dc1d9d50fba2f6a1ccab8748a0050cde38253f60/library/std/src/panicking.rs:579:13
   4: std::sys_common::backtrace::__rust_end_short_backtrace
             at /rustc/dc1d9d50fba2f6a1ccab8748a0050cde38253f60/library/std/src/sys_common/backtrace.rs:137:18
   5: rust_begin_unwind
             at /rustc/dc1d9d50fba2f6a1ccab8748a0050cde38253f60/library/std/src/panicking.rs:575:5
   6: core::panicking::panic_fmt
             at /rustc/dc1d9d50fba2f6a1ccab8748a0050cde38253f60/library/core/src/panicking.rs:64:14
   7: core::panicking::assert_failed_inner
   8: core::panicking::assert_failed
   9: <mozjs::rust::Runtime as core::ops::drop::Drop>::drop
  10: core::ptr::drop_in_place<mozjs::rust::Runtime>
  11: core::ptr::drop_in_place<script::script_runtime::Runtime>
  12: core::ptr::drop_in_place<script::script_thread::ScriptThread>
  13: std::sys_common::backtrace::__rust_begin_short_backtrace
  14: core::ops::function::FnOnce::call_once{{vtable.shim}}
  15: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/dc1d9d50fba2f6a1ccab8748a0050cde38253f60/library/alloc/src/boxed.rs:1988:9
      <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/dc1d9d50fba2f6a1ccab8748a0050cde38253f60/library/alloc/src/boxed.rs:1988:9
      std::sys::unix::thread::Thread::new::thread_start
             at /rustc/dc1d9d50fba2f6a1ccab8748a0050cde38253f60/library/std/src/sys/unix/thread.rs:108:17
  16: start_thread
  17: __clone3
mozilla::detail::MutexImpl::~MutexImpl: pthread_mutex_destroy failed: Device or resource busy
Caught signal 11 thread panicked while processing panic. aborting.
Redirecting call to abort() to mozalloc_abort
@mukilan mukilan added I-crash No impact; the issue is one of maintainability or tidiness. I-intermittent Problem reproduces intermittently. labels Aug 18, 2023
@mukilan mukilan changed the title Unexpected CRASH in /streams/readable-streams/crashtests/strategy-worker-terminate.html Intermittent CRASH in /streams/readable-streams/crashtests/strategy-worker-terminate.html Aug 18, 2023
@gterzian
Copy link
Member

gterzian commented Dec 20, 2023

The panic originates here in rustmozjs, which indicates that the parent runtime dropped with outstanding child runtimes.

This is more or less the flow:

  1. Child runtime for worker is created at

new_child_runtime(parent, Some(task_source))

  1. Handle to the worker is kept by the enclosing global scope.

global.track_worker(closing, join_handle, control_sender, context);

  1. The worker runs until the closing flag is set

while !scope.is_closing() {

  1. Terminate sets the flag(and requests an interrupt, in case the worker script is hanging).
  2. WorkerGlobalScope::clear_js_runtime is called, which should drop the child runtime owned by it.

At some point later, the enclosing scope should be shutdown, which calls into clear_js_runtime, which calls into remove_web_messaging_and_dedicated_workers_infra, which should shutdown worker and join on their threads.

What happens instead is that the script thread, and the parent runtime, is dropped before the worker and the child runtime.

My guess this is perhaps because it bypasses window.clear_js_runtime, and instead calls directly into window.clear_js_runtime_for_script_deallocation, which does not call into remove_web_messaging_and_dedicated_workers_infra.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-content/script Related to the script thread I-crash No impact; the issue is one of maintainability or tidiness. I-intermittent Problem reproduces intermittently. L-javascript Javascript is required
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants