1567941 - [10.15] Crash in [@ tcp_connection_fallback_handle_change_on_queue]

Status: RESOLVED DUPLICATE of bug 1567389

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

Description

[Marcia Knous [:marcia]]

Seen while looking at nightly crash data. This crash started in 20190717093640 and has 20 crashes/5 installs, all on macOS 10.15: https://bit.ly/2M6tZ9o.

Possible regression range based on build ID: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=57e096cabc296b897baec44b65ece648b54463c0&tochange=b6d154b2309846531934289c1e167208fc385ac3

Comment 1

[Michal Novotny [:michal]]

This is not a crash on our socket thread. I guess it's a crash in a thread that tries to upload a report to crash-stats? Anyway, all reports seem to have some exception on a thread which calls cubeb_init().

Comment 2

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Paul, would you mind first pass triaging this?

Comment 3

[Paul Adenot (:padenot)]

Attachment: Bug 1567941 - Don't initialize cubeb when decoding Opus in an RDD. r?mjf

Comment 4

[Paul Adenot (:padenot)]

This is trying to open cubeb from the RDD, and it can't, of course, it's locked down tighter than the content process and can't access what it needs. It's a bit surprising that it crashes instead of erroring out, but maybe it's what it does in Nightly.

Comment 5

[Paul Adenot (:padenot)]

Instead of this patch, we need to be able to know how many output channels the default audio output device has.

Comment 6

[Marcia Knous [:marcia]]

Last crashes in this signature were seen in 20190720214009.

Comment 7

[Pascal Chevrel:pascalc]

fix optional for 70 given the low volume

Comment 8

[Michael Froman [:mjf]]

Even though this crash is dropped to zero (mostly likely a result of Haik's fixes from Bug 1566540), it is caused by Opus touching audio backends on RDD (which is sandboxed more tightly than content processes). The change to fix how Opus handles the mono downmix decision is coming in Bug 1567389. I'm marking this bug a duplicate of Bug 1567389.