Closed Bug 1732479 Opened 3 years ago Closed 3 years ago

Crash in [@ core::result::unwrap_failed | futures_cpupool::impl$11::poll<T>]

Categories

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

Unspecified
Windows
defect

Tracking

()

RESOLVED FIXED
95 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- unaffected
firefox93 blocking fixed
firefox94 + fixed
firefox95 --- fixed

People

(Reporter: aryx, Assigned: kinetik)

References

(Regression)

Details

(Keywords: regression, topcrash)

Crash Data

Attachments

(1 file)

Firefox 94.0a1 20210924094613 and 93.0b9 on Windows 8.1 and 10 32-bit and 64-bit

media.audioipc.shm_area_size has 524288 as value for both 32- and 64-bit

Only website in the reports which reproduces the issue is epicgames.com, e.g. https://www.epicgames.com/store/en-US/p/the-escapists

Crash report: https://crash-stats.mozilla.org/report/index/19ceef81-e940-4243-904c-c0ab70210924

MOZ_CRASH Reason: called `Result::unwrap()` on an `Err` value: Error(Msg("mmap size"), State { next_error: None })

Top 10 frames of crashing thread:

0 xul.dll RustMozCrash mozglue/static/rust/wrappers.cpp:17
1 xul.dll mozglue_static::panic_hook mozglue/static/rust/lib.rs:91
2 xul.dll core::ops::function::Fn::call<void  ../c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/core/src/ops/function.rs:227
3 xul.dll std::panicking::rust_panic_with_hook ../c8dfcfe046a7680554bf4eb612bad840e7631c4b//library/std/src/panicking.rs:626
4 xul.dll std::panicking::begin_panic_handler::closure$0 ../c8dfcfe046a7680554bf4eb612bad840e7631c4b//library/std/src/panicking.rs:519
5 xul.dll std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::closure$0, never$> ../c8dfcfe046a7680554bf4eb612bad840e7631c4b//library/std/src/sys_common/backtrace.rs:141
6 xul.dll std::panicking::begin_panic_handler ../c8dfcfe046a7680554bf4eb612bad840e7631c4b//library/std/src/panicking.rs:515
7 xul.dll core::panicking::panic_fmt ../c8dfcfe046a7680554bf4eb612bad840e7631c4b//library/core/src/panicking.rs:92
8 xul.dll core::result::unwrap_failed ../c8dfcfe046a7680554bf4eb612bad840e7631c4b//library/core/src/result.rs:1599
9 xul.dll futures_cpupool::impl$11::poll<futures::future::catch_unwind::CatchUnwind<std::panic::AssertUnwindSafe<futures::future::lazy::Lazy<audioipc_client::stream::impl$1::process::closure$0, enum$<core::result::Result<enum$<audioipc::messages::CallbackResp>, tuple$<> >, 0, 3, Ok> > > > > third_party/rust/futures-cpupool/src/lib.rs:333
Flags: needinfo?(kinetik)
Has Regression Range: --- → yes
Crash Signature: [@ core::result::unwrap_failed | futures_cpupool::impl$11::poll<T>] → [@ core::result::unwrap_failed | futures_cpupool::impl$11::poll<T>] [@ core::result::unwrap_failed | futures_cpupool::{{impl}}::poll<T>]

I requested a backout of the problematic changes in bug 1730518 comment 20 that'll address this for beta.

The Epic Games Store trailers are serving 192kHz stereo audio, which in addition to a possible bug in cubeb_wasapi's latency calculation caused the audio stream to need ~675kB of shmem, larger than the 128kB/512kB limit set via the pref. With the previous 2MB limit, this is unlikely to crash - but I'm working on a fix for nightly.

Assignee: nobody → kinetik
Severity: -- → S2
Status: NEW → ASSIGNED
Crash Signature: [@ core::result::unwrap_failed | futures_cpupool::impl$11::poll<T>] [@ core::result::unwrap_failed | futures_cpupool::{{impl}}::poll<T>] → [@ core::result::unwrap_failed | futures_cpupool::impl$11::poll<T>] [@ core::result::unwrap_failed | futures_cpupool::{{impl}}::poll<T>]
Flags: needinfo?(kinetik)
Priority: -- → P2

The backouts are done for beta, so I am marking this one fixed for 93, thanks.

Hi Matthew, where do we stand with all of this for 94+? AFAICT, the backout from comment 1 has helped things for Beta94, but hasn't fully eliminated issues either.

Flags: needinfo?(kinetik)

(In reply to Ryan VanderMeulen [:RyanVM] from comment #5)

Hi Matthew, where do we stand with all of this for 94+? AFAICT, the backout from comment 1 has helped things for Beta94, but hasn't fully eliminated issues either.

The root cause of these crashes will be addressed in bug 1730518. A fix is under review now, it's intended to be safe enough for beta94 uplift and should be ready early this week.

I'll keep this bug open for now - the immediate crashes here were addressed by the backout in comment 1, but I have a fix for the Windows cubeb backend to address a related issue I found in comment 3.

Flags: needinfo?(kinetik)
Pushed by rvandermeulen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c7768090c505
Update libcubeb to 8ef5a1ff.  r=cubeb-reviewers,padenot
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 95 Branch

Please nominate this for Beta approval ASAP.

Flags: needinfo?(kinetik)

Thanks for ping!

The libcubeb fix isn't necessary on beta. I'll mark this as fixed in b94 since the crash isn't present after this backout.

I've nominated the crash fix in bug 1730518 for beta uplift.

Flags: needinfo?(kinetik)
You need to log in before you can comment on or make changes to this bug.