1133444 - crash in libsystem_pthread.dylib@0x49a4 (called from DeviceChangeCallback after USB headset removal)

Status: RESOLVED FIXED

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

Description

[Martijn Wargers (dead)]

This bug was filed from the Socorro interface and is 
report bp-2d70c5d0-8537-4190-9fc1-4ce7f2150215.
=============================================================
0 	libsystem_pthread.dylib 	libsystem_pthread.dylib@0x49a4 	
Ø 1 	libsystem_pthread.dylib 	libsystem_pthread.dylib@0x4620 	
Ø 2 	libsystem_pthread.dylib 	libsystem_pthread.dylib@0x46e9 	
3 	libnss3.dylib 	PR_Lock 	nsprpub/pr/src/pthreads/ptsynch.c
4 	XUL 	mozilla::AudioCallbackDriver::DeviceChangedCallback() 	obj-firefox/x86_64/dist/include/mozilla/Mutex.h
5 	XUL 	audiounit_property_listener_callback 	media/libcubeb/src/cubeb_audiounit.c


I get this crash after I made a call on www.voipstunt.com. I use MacOsX10.9.5.

Steps to reproduce:
- Go to https://www.voipstunt.com (I have credits to make calls there)
- I have my usb headset plugged in
- Make a phone call to someone
- After the call is finished, unplug your headset
- Close the lid of your laptop
- After a while, reopen it

Actual result:
- Firefox has crashed, the crash reporter shows

Comment 1

[Paul Adenot (:padenot)]

Maybe we need to unregister and reregister the listeners since they are bound to the output device (A particular AudioDeviceId), and it changed.

This means we would error out when calling audiounit_uninstall_device_changed_callback.

Comment 2

[Paul Adenot (:padenot)]

This looks like it's rare enough, I'll get to it after more urgent crashes.

Comment 3

[Haakon Sporsheim [:haaspors] (Telenor)]

Seems similar to Bug 1129166

I'm wondering how the apple property listeners are thread safe at all.

Firefox sets kAudioHardwarePropertyRunLoop with runLoop = nullptr which means that property changed notifications will be delivered from its own thread AFAIU. (I haven't found any apple docs saying how this actually works). So how can we make this thread safe? In theory a notification could be delivered at the same time as we remove the listener and free the cubeb stream structure. Seems quite obvious to me that this have to fail/crash. Not sure how to fix it though.

Comment 4

[Paul Adenot (:padenot)]

Can we not lock ?

Comment 5

[Paul Adenot (:padenot)]

That should be fixed by your recent work, right ?

Comment 6

[Alex Chronopoulos [:achronop]]

Yeah, last time I saw this signature in crash-stat was many months (versions) ago.