Closed Bug 1644227 Opened 2 years ago Closed 2 years ago

Crash in [@ futures::task_impl::current]

Categories

(Core :: Audio/Video: cubeb, defect, P2)

78 Branch
x86_64
Windows
defect

Tracking

()

RESOLVED FIXED
mozilla79
Tracking Status
firefox-esr68 --- unaffected
firefox77 --- unaffected
firefox78 --- fixed
firefox79 --- fixed

People

(Reporter: philipp, Assigned: kinetik)

References

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

This bug is for crash report bp-0357c913-1ff1-40c9-8a71-a86d80200606.

Top 10 frames of crashing thread:

0 xul.dll RustMozCrash mozglue/static/rust/wrappers.cpp:16
1 xul.dll mozglue_static::panic_hook mozglue/static/rust/lib.rs:89
2 xul.dll core::ops::function::Fn::call<fn ../4fb7144ed159f94491249e86d5bbd033b5d60550/src/libcore/ops/function.rs:232
3 xul.dll std::panicking::rust_panic_with_hook ../4fb7144ed159f94491249e86d5bbd033b5d60550//src/libstd/panicking.rs:474
4 xul.dll std::panicking::begin_panic<str*> ../4fb7144ed159f94491249e86d5bbd033b5d60550/src/libstd/panicking.rs:397
5 xul.dll futures::task_impl::current third_party/rust/futures-0.1.23/src/task_impl/mod.rs:100
6 xul.dll tokio_reactor::registration::Registration::poll_write_ready third_party/rust/tokio-reactor/src/registration.rs:347
7 xul.dll tokio_reactor::poll_evented::PollEvented<mio_named_pipes::NamedPipe>::poll_write_ready<mio_named_pipes::NamedPipe> third_party/rust/tokio-reactor/src/poll_evented.rs:318
8 xul.dll tokio_reactor::poll_evented::PollEvented<mio_named_pipes::NamedPipe>::clear_write_ready<mio_named_pipes::NamedPipe> third_party/rust/tokio-reactor/src/poll_evented.rs:355
9 xul.dll audioipc::messagestream_win::{{impl}}::write_buf<std::io::cursor::Cursor<bytes::bytes::Bytes>> media/audioipc/audioipc/src/messagestream_win.rs:96

this browser crash signature is spiking up during the firefox 78 cycle with MOZ_CRASH Reason no Task is currently running.

Severity: -- → S3
Flags: needinfo?(kinetik)
Priority: -- → P2

ServerHandler is being dropped inside Tokio via release_node as part of the internal runtime shutdown. When ServerHandler is dropped, we call Sink::close primarily for the side effect of closing the underlying I/O stream. The docs for Sink state that a panic may occur if "it is called outside the context of a future's task", which is what's happening here.
Tokio manages the futures task executor TLS for us, and it's not clear if it's a bug or intentional that the task drop is run outside the task context here.

In either case, we can use futures::task::is_in_task (added in futures 0.1.27) inside our Sink::close impl to avoid calling poll_complete in the situation where it'd panic.

Assignee: nobody → kinetik
Status: NEW → ASSIGNED
Flags: needinfo?(kinetik)

Anything we can do here in the short term for 78? So far this is the #15 top browser crash in 78.0b7, and we're going into RC next week.

Attached file GitHub Pull Request

Forgot to link the related fix PR. This is merged upstream. I'm now waiting on bug 1644522/PR 101 to be reviewed, then I'll import both fixes and prepare a patch for beta uplift.

Depends on: 1646576
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla79
You need to log in before you can comment on or make changes to this bug.