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

RESOLVED FIXED

Status

()

Core
WebRTC: Audio/Video
P2
major
Rank:
28
RESOLVED FIXED
3 years ago
a year ago

People

(Reporter: Martijn Wargers (zombie), Assigned: padenot)

Tracking

({crash})

Trunk
All
Mac OS X
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

(Reporter)

Description

3 years ago
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

Updated

3 years ago
Summary: crash in libsystem_pthread.dylib@0x49a4 → crash in libsystem_pthread.dylib@0x49a4 (called from DeviceChangeCallback after USB headset removal)
(Assignee)

Comment 1

3 years ago
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.
(Assignee)

Updated

3 years ago
Assignee: nobody → padenot
(Assignee)

Comment 2

3 years ago
This looks like it's rare enough, I'll get to it after more urgent crashes.
Severity: critical → major
backlog: --- → webRTC+
Rank: 28
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.
(Assignee)

Comment 4

3 years ago
Can we not lock ?
(Assignee)

Comment 5

a year ago
That should be fixed by your recent work, right ?
Flags: needinfo?(achronop)
Yeah, last time I saw this signature in crash-stat was many months (versions) ago.
Status: NEW → RESOLVED
Last Resolved: a year ago
Flags: needinfo?(achronop)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.