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
Summary: crash in libsystem_pthread.dylib@0x49a4 → crash in libsystem_pthread.dylib@0x49a4 (called from DeviceChangeCallback after USB headset removal)
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.
This looks like it's rare enough, I'll get to it after more urgent crashes.
Severity: critical → major
backlog: --- → webRTC+
Priority: -- → P2
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.
Can we not lock ?
That should be fixed by your recent work, right ?
Yeah, last time I saw this signature in crash-stat was many months (versions) ago.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.