Closed Bug 1692910 Opened 5 years ago Closed 5 years ago

Crash in [@ cubeb_coreaudio::backend::set_volume]

Categories

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

Desktop
macOS
defect

Tracking

()

RESOLVED FIXED
88 Branch
Tracking Status
firefox-esr78 --- wontfix
firefox86 --- wontfix
firefox87 --- wontfix
firefox88 --- fixed

People

(Reporter: mstange, Assigned: chunmin)

References

(Blocks 1 open bug)

Details

(Keywords: crash)

Crash Data

Attachments

(3 files)

Crash report: https://crash-stats.mozilla.org/report/index/c83a4ba8-25b0-41a3-b141-08d9a0210214

MOZ_CRASH Reason: assertion failed: !unit.is_null()

Top 10 frames of crashing thread:

0 XUL RustMozCrash mozglue/static/rust/wrappers.cpp:17
1 XUL mozglue_static::panic_hook mozglue/static/rust/lib.rs:89
2 XUL core::ops::function::Fn::call /builds/worker/fetches/rustc/lib/rustlib/src/rust/library/core/src/ops/function.rs:70
3 XUL std::panicking::rust_panic_with_hook library/std/src/panicking.rs:595
4 XUL std::panicking::begin_panic_handler::{{closure}} library/std/src/panicking.rs:495
5 XUL std::sys_common::backtrace::__rust_end_short_backtrace library/std/src/sys_common/backtrace.rs:141
6 XUL rust_begin_unwind library/std/src/panicking.rs:493
7 XUL core::panicking::panic_fmt library/core/src/panicking.rs:92
8 XUL core::panicking::panic library/core/src/panicking.rs:50
9 XUL cubeb_coreaudio::backend::set_volume third_party/rust/cubeb-coreaudio/src/backend/mod.rs:268

Perhaps this can happen if reinit fails, resulting in a null output_device used in set_volume where the assert triggers. That might require a race between the set_volume call and reinit closing the devices and the error callback being handled upstream.

Flags: needinfo?(cchang)
Severity: -- → S3
Priority: -- → P3

I'll take a look and see if I can reproduce this.

(In reply to Matthew Gregan [:kinetik] from comment #1)

Perhaps this can happen if reinit fails, resulting in a null output_device used in set_volume where the assert triggers. That might require a race between the set_volume call and reinit closing the devices and the error callback being handled upstream.

It seems it's a possible cause. I'll test it. Thanks for the hints! Keep the NI for now until I get back to this bug.

Assignee: nobody → cchang
Attached file GitHub Pull Request

This should fix the issue

Flags: needinfo?(cchang)
Priority: P3 → P1
Hardware: Unspecified → Desktop

Depends on D106252

Pushed by cchang@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/198f8a1be146 P1: Update cubeb-coreaudio to ad56ea1 r=cubeb-reviewers,kinetik https://hg.mozilla.org/integration/autoland/rev/dbee99d1a1b7 P2: mach vendor rust r=cubeb-reviewers,kinetik
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 88 Branch
Blocks: 1530713
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: