1631814 - Crash in [@ CoreAudio@0xc6ca]

Status: NEW

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

Description

[Alex Chronopoulos [:achronop]]

This bug is for crash report bp-917b74c9-7fb3-49d5-85c0-1dd3c0200419.

Top 6 frames of crashing thread:

0 CoreAudio CoreAudio@0xc6ca 
1 CoreAudio ___ZN19HALC_ProxyIOContextC2Ejj_block_invoke 
2 CoreAudio HALB_IOThread::Entry 
3 libsystem_pthread.dylib _pthread_start 
4 libsystem_pthread.dylib thread_start 
5 CoreAudio HALB_IOThread::StartAndWaitForState 

It has appeared 31 times since 20200309095159 and 2 times in esr 68

Comment 1

[C.M.Chang[:chunmin]]

Not have a clear idea what happens. Make it P3 for now.

Comment 2

[Jonathan Lennox]

The following steps reproduce this pretty reliably for me (75% of the time at least). I haven't experimented to see how many of these steps are actually necessary.

1. Have a MacBook pro with an external monitor and webcam. (In case it matters, the external monitor is an LG Ultrawide, which is retina). I'm running macOS Mojave 10.14.6 (18G4032).

2. Start Firefox Nightly (77.0a1 (2020-04-21) (64-bit)) with the laptop lid closed, so all windows are on the external monitor.

3. Go to https://meet.jit.si/SomeArbitraryConference. Select the webcam as the camera and microphone. (Note that explicitly selecting the camera and microphone in Firefox's dialogs may be necessary; if you have history with meet.jit.si you may need to open in a private window.)

4. Open the laptop lid. Windows move to the laptop screen.

5. Drag the Firefox nightly window back to the external monitor.

6. Close the laptop lid. All windows move back to the external monitor.

The crash will happen sometime during this process.

Comment 3

[Jonathan Lennox]

One specific crash that happened for me following this process: bp-b100147d-2361-43dc-be48-280990200422.

Comment 4

[C.M.Chang[:chunmin]]

(In reply to Jonathan Lennox from comment #2)

The following steps reproduce this pretty reliably for me (75% of the time at least). I haven't experimented to see how many of these steps are actually necessary.

1. Have a MacBook pro with an external monitor and webcam. (In case it matters, the external monitor is an LG Ultrawide, which is retina). I'm running macOS Mojave 10.14.6 (18G4032).

2. Start Firefox Nightly (77.0a1 (2020-04-21) (64-bit)) with the laptop lid closed, so all windows are on the external monitor.

3. Go to https://meet.jit.si/SomeArbitraryConference. Select the webcam as the camera and microphone. (Note that explicitly selecting the camera and microphone in Firefox's dialogs may be necessary; if you have history with meet.jit.si you may need to open in a private window.)

4. Open the laptop lid. Windows move to the laptop screen.

5. Drag the Firefox nightly window back to the external monitor.

6. Close the laptop lid. All windows move back to the external monitor.

The crash will happen sometime during this process.

Unfortunately, I cannot reproduce this on my MacBook Pro 2017 with Mac OS 10.15.2 (Catalina). I've tried to open and close lid several time or move the windows back and forth between laptop screen to external monitor but no crashes happens.

I have no idea why Firefox crashes in CoreAudio. The microphone stays the same during the whole process. If the output device also stays the same as well, then there is no audio device changed in between.

Jonathan Lennox, is the output device changed during this process?

Comment 5

[C.M.Chang[:chunmin]]

Jonathan Lennox,

Would you mind getting the log when Firefox crashes, by launching Firefox Nightly with the following command in terminal?

MOZ_LOG="cubeb:5" /Applications/Firefox\ Nightly.app/Contents/MacOS/firefox-bin

you would see lots of message like this:

[Child xxx: MediaDecoderStateMachine #x]: E/cubeb /builds/worker/checkouts/gecko/third_party/rust/cubeb-coreaudio/src/backend/mod.rs:2678: (0x123456789) Output audiounit init with device 123 successfully.

After the log is enabled, can you do the steps in #comment 2 to get a crash in Firefox, then upload the logs to here? It would be nice to see what's going on.

Comment 6

[Jonathan Lennox]

Attachment: Moz-cubeb-crash.txt

Here's the requested output, with the crash.

Comment 7

[Jonathan Lennox]

I'm not changing the audio output device on purpose, but it's possible that opening or closing the laptop lid changes the default device? My normal default audio output device is my external monitor.

Comment 8

[C.M.Chang[:chunmin]]

(In reply to Jonathan Lennox from comment #6)

Created attachment 9143094 [details]
Moz-cubeb-crash.txt

Here's the requested output, with the crash.

Thanks for the help!

(In reply to Jonathan Lennox from comment #7)

I'm not changing the audio output device on purpose, but it's possible that opening or closing the laptop lid changes the default device? My normal default audio output device is my external monitor.

From the log, it seems the DisplayPort audio output (the external monitor) is added and removed again and again, and DisplayPort is the default output device so the default output device is changed when that happens, which makes the underlying audio streams re-initialize to follow the new default output device. It seems Firefox would crash if this process is repeated frequently.

I am not clear what causes the crash actually. But I do spot something weird

1. If the underlying audio stream is being reinitialized while the default output device is changing, sometimes the new default would return kAudioObjectUnknown instead of a valid AudioDeviceID even the system still have valid devices.

   • For example, when the DisplayPort is unplugged, we get this error in the log @ 4880 line states

   [..thread 0x182d04420]: E/cubeb mod.rs:207: Could not find default audio device for OUTPUT

   • but actually there are other devices in the system
   • (The DisplayPort is plugged back soon)

2. The above leads to a failure of reinitializing the audio stream and log the error messages here and here

From the log, I am not able to infer which line causes the crash. But I guess the Firefox crashes when trying to relaunch a new audio stream when the stream reinitialization fails, since the last log is "Fail to create device info for output".

I do spot other defects in our code when reading the logs. I will leave other things in the following comments.

Comment 9

[C.M.Chang[:chunmin]]

There are some defects in our code:

• The properties of a duplex stream are initialized with different devices when we use an internal aggregate device. The AudioUnit with out_dev_info but current_latency_frames and output_source_listener will be set via output_device. The output_device and out_dev_info are different values when we use an internal aggregate device for the duplex stream.
• In ({:p}) Cubeb stream init successful., the {:p} is not matched the stream identifier we constantly used
• Some logs are not paired with the stream identifier so it not clear what stream the logs are from
• It's better to log what stream is being reinitialized
• The default device is not printed within cubeb-coreaudio's logs itself although it's not hard to guess when reading the log from cubeb.c.

Comment 10

[C.M.Chang[:chunmin]]

(In reply to C.M.Chang[:chunmin] from comment #8)

Here are other things I don't know

I am not clear what causes the crash actually. But I do spot something weird

1. If the underlying audio stream is being reinitialized while the default output device is changing, sometimes the new default would return kAudioObjectUnknown instead of a valid AudioDeviceID even the system still have valid devices.

1. From the log, it seems that Firefox would launch a new duplex stream automatically when the above problem happens:
   • @ line 4882 in the log:

   E/cubeb mod.rs:3315: (0x1862d7800) Could not reopen the stream after switching.

   • @ line 4931 in the log:

   E/cubeb mod.rs:2215: (0x70000cd712b0) Cubeb stream init successful.

   • @ line 4932 in the log:

   E/cubeb mod.rs:3375: Cubeb stream (0x1862d7800) destroyed successful.

   • @ line 4933 in the log:

   E/cubeb mod.rs:3404: Cubeb stream (0x186295c00) started successfully.

2. There is a output-only stream(e.g. 0x18d5d7c00 in the log) constantly be created with the duplex stream (e.g. 0x1862d7800 in the log) used for WebRTC.

Paul, does this re-launch process is done in MediaStreamGraph when cubeb run into an error state? does MediaStreamGraph open a shadow output stream when Firefox create a duplex stream for WebRTC?

Comment 11

[C.M.Chang[:chunmin]]

(In reply to C.M.Chang[:chunmin] from comment #8)

1. If the underlying audio stream is being reinitialized while the default output device is changing, sometimes the new default would return kAudioObjectUnknown instead of a valid AudioDeviceID even the system still have valid devices.

   • For example, when the DisplayPort is unplugged, we get this error in the log @ 4880 line states

   [..thread 0x182d04420]: E/cubeb mod.rs:207: Could not find default audio device for OUTPUT

   • but actually there are other devices in the system
   • (The DisplayPort is plugged back soon)

I remember I've ran into this problem when trying to deal with bug 1586379.

Comment 12

[Paul Adenot (:padenot)]

(In reply to C.M.Chang[:chunmin] from comment #10)

Paul, does this re-launch process is done in MediaStreamGraph when cubeb run into an error state? does MediaStreamGraph open a shadow output stream when Firefox create a duplex stream for WebRTC?

Yes, here. This switches to a fallback driver that then attempts to re-open a normal AudioCallbackDriver periodically.