Apple

Actually, the property listener parts can be disregarded, it's enough to just poll the property in question on another thread. Eventually the main thread blows up here:

Thread 0 Crashed:: CrBrowserMain Dispatch queue: com.apple.main-thread
0 com.apple.audio.units.Components 0x7000d288 AUHAL::UpdateStreamFormats() + 164
1 com.apple.audio.units.Components 0x7000ba95 AUHAL::SelectDevice(unsigned long) + 1285
2 com.apple.audio.units.Components 0x7000b0ff AUHAL::HALListener(unsigned long, unsigned long, AudioObjectPropertyAddress const*, void*) + 125
3 com.apple.audio.CoreAudio 0x9959c73b HALPropertyListener_Call_Helper(long, void*, void*, unsigned long, unsigned long, AudioObjectPropertyAddress const*) + 339

<...>

This now definitely looks like a thread safety bug so I'll go ahead and report it as such.

- dale

On Tue, Feb 5, 2013 at 5:45 PM, Dale Curtis <email@hidden> wrote:

Hi all,

Chrome is hitting a lot of crashes in HALPropertyListener_Call_Helper which appear to be due to the usage of property listeners and CoreAudio calls to the listener address on threads other than the main thread. A lot in this case is ~25% of all Chrome Mac crashes.

The tl;dr question is: When property listener callbacks are used, is it safe to call CoreAudio methods addressed for the same property from a different thread? Specifically on a thread other than the main thread.

The details; the two threads in question are:
- The main process thread: BrowserMainThread. Has a CFRunLoop. Creates the AudioThread.
- The thread on which CoreAudio methods are called and property listeners created: AudioThread.

The property we're listening for changes to:
// Property address to monitor for device changes.
const AudioObjectPropertyAddress kDefaultOutputDevicePropertyAddress = {

kAudioHardwarePropertyDefaultOutputDevice,
kAudioObjectPropertyScopeGlobal,
kAudioObjectPropertyElementMaster
};

When we receive the property change event:

- We send an asynchronous message to the AudioThread indicating it should handle a device change and exit the property listener handler immediately.
- On the AudioThread we query for the new output device and the new hardware sample rate.

If we don't register any property listeners, we don't see any crashes. However, once we've created a property listener, it's a dice roll with each listener callback until the crash occurs.

The crash itself takes place in BrowserMainThread while AudioThread issues an AudioObjectGetPropertyData for the same kDefaultOutputDevicePropertyAddress used by the listener. See http://crbug.com/158170 for more details.

On 10.6 everything works correctly once we set kAudioHardwarePropertyRunLoop to point to the CFRunLoop owned by AudioThread.

On 10.7 kAudioHardwarePropertyRunLoop appears broken and in 10.8 looks deprecated, so we've attempted to use the new AudioObject(Add|Remove)PropertyListenerBlock methods and replace AudioThread with a dispatch queue. Sadly, this doesn't work either and we're still seeing the same crashes.

The one thing that has resolved all crashes on 10.7+ is to move all CoreAudio calls onto the BrowserMainThread; however that has non-trivial implications for Chrome, so we'd prefer to avoid doing that.

Any pointers would be appreciated. If this sounds like a bug, I'll refile as appropriate.

Thanks in advance!

- dale