This bug was filed from the Socorro interface and is report bp-4acf1fc6-d886-4498-9eb1-ee7680180124. ============================================================= Top 10 frames of crashing thread: 0 firefox mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:33 1 firefox abort memory/mozalloc/mozalloc_abort.cpp:80 2 libxul.so std::panicking::rust_panic src/libpanic_abort/lib.rs:59 3 libxul.so std::panicking::rust_panic_with_hook src/libstd/panicking.rs:593 4 libxul.so std::panicking::begin_panic<alloc::string::String> src/libstd/panicking.rs:538 5 libxul.so std::panicking::begin_panic_fmt src/libstd/panicking.rs:522 6 libxul.so core::panicking::panic_fmt src/libstd/panicking.rs:498 7 libxul.so core::panicking::panic_bounds_check src/libcore/panicking.rs:58 8 libxul.so cubeb_pulse::capi::capi_get_preferred_channel_layout media/libcubeb/cubeb-pulse-rs/src/backend/context.rs:42 9 libxul.so audioipc_server::{{impl}}::process media/cubeb-rs/cubeb-api/src/context.rs:67 ============================================================= There are 2 crashes (from the same installation) in nightly 60. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1428952. [1] https://hg.mozilla.org/mozilla-central/rev/5f79f72ac9fe

Asking for a layout that's not in the table? Hmmm...

I don't see any recent crashes in Nightly 60. I do see a Linux user crashing in 59b4 (maybe the same user?). Adding 59 as affected.

cubeb-pulse-rs was using out-of-date bindings to cubeb library. The layout structure changed and wasn't updates. cubeb-pulse-rs has since been changed to use a common cubeb FFI wrapper, that comes with checks against the cubeb C version it's built against, in Bug 1440538.