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

This should be fixed by the following backout: https://hg.mozilla.org/integration/autoland/rev/0b4005ebc9776ff43d99d1427c1a1fd2e14d9a44

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.

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.

(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.

https://hg.mozilla.org/mozilla-central/rev/c7768090c505

Please nominate this for Beta approval ASAP.

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.