CoreAudio driver prone to deadlocks
Brought to you by:
mywave
Menu
▾
▴
#12 CoreAudio driver prone to deadlocks
The CoreAudio driver is prone to deadlocking. Just now, ocp 0.1.21 built via HomeBrew on MacOSX 10.7.3 hung, and GDB shows this stacktrace:
#0 0x00007fff92dd1bf2 in __psynch_mutexwait () #1 0x00007fff8f9391a1 in pthread_mutex_lock () #2 0x00000001072f5bb3 in CoreAudioGetBufPos () #3 0x00000001072e8e37 in mixmain () #4 0x00000001072e9589 in timerproc () #5 0x0000000107270343 in tmTimerHandler () #6 <signal handler called> #7 0x00007fff8f98054c in OSAtomicCompareAndSwapPtrBarrier$VARIANT$mp () #8 0x00007fff8f939160 in pthread_mutex_lock () #9 0x00000001072f5c26 in CoreAudioGetPlayPos () #10 0x00000001072d039d in plrGetRealMasterVolume () #11 0x000000010740a2af in drawpeakpower () #12 0x000000010740a08e in MVolDraw () #13 0x000000010740e5a9 in txtDraw () #14 0x0000000107404122 in plmpCallBack () #15 0x00000001072a212a in _fsMain () #16 0x00000001072619e2 in _bootup () #17 0x0000000107229542 in ?? () #18 0x0000000107228354 in ?? ()
It looks like "devp/devpcoreaudio.c" is using pthread_mutex_lock inside a signal handler, but the signal handler may be called on a thread that already holds the lock, so the thread deadlocks.
(Also the code includes a comment "/ this thing is utterly broken /" with no further explanation)
Possibly relevant links:
http://www.kaourantin.net/2006/08/pthreads-and-signals.html
http://manpages.ubuntu.com/manpages/jaunty/man3/pthread_mutex_init.3.html (section "async-signal safety")