1746533 - Crash in [@ core::option::expect_failed | <async_task::task::Task<T> as core::future::future::Future>::poll] with "task has failed"

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Andrew McCreight [:mccr8]]

Crash report: https://crash-stats.mozilla.org/report/index/6777247c-f8c7-4f6e-8598-8a64f0211210

MOZ_CRASH Reason: task has failed

Top 10 frames of crashing thread:

0 XUL RustMozCrash mozglue/static/rust/wrappers.cpp:18
1 XUL mozglue_static::panic_hook mozglue/static/rust/lib.rs:91
2 XUL core::ops::function::Fn::call library/core/src/ops/function.rs:70
3 XUL std::panicking::rust_panic_with_hook library/std/src/panicking.rs:628
4 XUL std::panicking::begin_panic_handler::{{closure}} library/std/src/panicking.rs:521
5 XUL std::sys_common::backtrace::__rust_end_short_backtrace library/std/src/sys_common/backtrace.rs:139
6 XUL rust_begin_unwind library/std/src/panicking.rs:517
7 XUL core::panicking::panic_fmt library/core/src/panicking.rs:100
8 XUL core::panicking::panic_display library/core/src/panicking.rs:64
9 XUL core::option::expect_failed library/core/src/option.rs:1638

This stack is not very informative, but this error message was added in bug 1739727. The first build with this crash is 20211208095339, which does line up with the landing of this bug. This might just be a signature change for Rust task failure crashes.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1739727

Comment 2

[Christian Holler (:decoder)]

Needinfo based on comment 1, :nika can you look into this or forward the needinfo? Thanks!

Comment 3

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1746533 - Part 2: Use the fallible Poll implementation in moz_task, r=emilio

This helps fix a crash being caused by the runnable created by the
moz_task library being dropped when a dispatch to a background thread
fails. The async_task library was written assuming that panics are
recoverable, and doesn't provide a way to recover from task cancellation
other than handling panics, which are hard crashes in Gecko.

To work around this issue for now, this patch wraps the
async_task::Runnable object in a ManuallyDrop to prevent it being
destroyed if the runnable is not executed, and replaces the crash with a
debug-only assertion closer to the source of the issue.

In the future we may want to be able to handle cancelled tasks better,
but we'll need to make modifications to async_task to make that
happen.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

I hit this relatively often on macOS fwiw.

Comment 5

[Nika Layzell [:nika] (ni? for response)]

I have filed and gotten merged a change to the async_task crate to allow us to manually handle cancelled tasks (https://github.com/smol-rs/async-task/pull/21). A new release hasn't been cut yet, but I can add a git dependency for the updated version.

Comment 6

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1746533 - Part 1: Use custom vendored version of async-task, r=emilio

This version adds a new FallibleTask wrapper type which allows polling the
task without panicking.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/aeec2a03935f
Part 1: Use custom vendored version of async-task, r=emilio
https://hg.mozilla.org/integration/autoland/rev/f5f803c35e09
Part 2: Use the fallible Poll implementation in moz_task, r=emilio

Comment 8

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/aeec2a03935f
https://hg.mozilla.org/mozilla-central/rev/f5f803c35e09