Re: What is causing this deadlock?
Re: What is causing this deadlock?
- Subject: Re: What is causing this deadlock?
- From: Bob Stuller <email@hidden>
- Date: Fri, 25 Jan 2008 16:54:09 -0500
Sorry that I had to edit the hang report following the body of the
email. The list server draws the line at 12k.
Jeff, Greetings!
At 12:05 PM -0800 1/25/08, Jeff Moore wrote:
Every so often the problem arises right after we've taken hog mode
successfully. You can see in the stack of the work thread:
AudioDeviceSetProperty >> HALObject::SetPropertyData >>
HALPlugIn::ObjectSetPropertyData >>
IOA_SingleDevice::SetPropertyData >> HP_HogMode::Take >>
IOA_SingleDevice::HogModeStateChanged >> CAMutex::Lock >>
pthread_mutex_lock >> semaphore_wait_signal_trap
Over on the main thread, you see the following in the stack:
CFRunLoopRunSpecific >> __CFMachPortPerform >>
IOA_HWDevice::MachPortCallBack >>
IOA_SingleDevice::HWDevice_FormatChanged >> CAMutex::Lock >>
pthread_mutex_lock >> semaphore_wait_signal_trap
Can you post a sample trace with the full backtraces?
Edited at the end of this email.
Thanks for looking this over. As I had noted, I was basing my
questions partially on conjecture.
Some questions that occurred to me, partially based on conjecture:
Why is the IOA_SingleDevice notifying itself?
Not sure what you mean. The HAL is written in C++ and the back trace
just shows the control flow moving between various implementation
objects.
There are 2 back-traces here. The non-BlueTask thread's back-trace
has an IOA_SingleDevice whose HogModeStateChanged method locks the
mutex.
Now, as you point out, it might just be a coincidence, that the main
thread is calling into a HWDevice's MachPortCallBack which in turn
calls into a IOA_SingleDevice also & that object instance (indeed,
there is no way to tell that it's the same instance of
IOA_SingleDevice) has its method FormatChanged called, which is also
calling CAMutex::Lock.
Why is Hog mode being notified as a format change?
It is not. You are presuming that the two are related rather than
just coincidental.
You are absolutely right that I am working in the dark here. No
source code to look at, I have to infer things as best I can. If I
had the source code I would know if the two IOA_SingleDevice
instances are in fact the same instance. Further, I would be able to
tell whether IOA_SingleDevice uses the same CAMutex instance for both
HogModeStateChanged & FormatChanged.
But this pair of stack crawls is repeatable. I have a bunch from the
beta-testers too. So it is more than cosmic-ray random.
I have a possibly related question. I've set the BlueTask run-loop
as the preferred place to receive notifications from Core Audio. At
the point in time that this occurs I only have two listeners, one on
the hardware to hear about changes to the list of input devices &
'DeviceIsAlive' on the device that we're soon going to be pulling
audio from. Will other notifications occur on that run loop without
a callback being registered for them?
Is the same CAMutex instance used in both IOA_SingleDevice methods?
What am I doing wrong?
Hard to say without more context.
A more complete hang report follows my signature. Thank you for
taking the time to look this over.
Peace,
Bob
--
OS Version: 10.5.1 (Build 9B18)
Architecture: i386
Event: hang
[snip]
21 _NSApplicationMain + 574
21 -[NSApplication run] + 795
21 -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
21 __DPSNextEvent + 657
21 _BlockUntilNextEventMatchingListInMode + 106
21 _ReceiveNextEventCommon + 175
21 _RunCurrentEventLoopInMode + 283
21 _CFRunLoopRunInMode + 88
21 _CFRunLoopRunSpecific + 3921
21 ___CFMachPortPerform + 117
21
__ZN12IOA_HWDevice16MachPortCallBackEP12__CFMachPortPvlS2_ + 504
21
__ZN16IOA_SingleDevice22HWDevice_FormatChangedEP12IOA_HWDeviceP12IOA_HWStream
+ 67
21 _semaphore_wait_signal_trap + 10
(in libSystem.B.dylib)
Thread id: 95343c8
User stack:
21 _thread_start + 34 (in libSystem.B.dylib)
21 __pthread_start + 321 (in libSystem.B.dylib)
21 ___NSThread__main__ + 308 (in Foundation)
21 -[NSThread main] + 45 (in Foundation)
21 -[MSAppDelegate reactToIsMicOn:] + 190 (in our app)
21 __ZN11MSInterface11SetMicStateEPP16DSXMicState_fakeb
+ 189 (in our app)
21 __ZN14ClsDemonThread11setMicStateEtii + 97 (in our app)
21 __ZN20ClsModularRecognizer11setMicStateEti + 549
(in our app)
21
__ZN20ClsModularRecognizer10setWarpingEPP12SDhUser_fakePP15SDhSigProc_fake
+ 890 (in our app)
21 __ZN14MSAudioChannel16SetMicOnCallBackEPv +
87 (in our app)
21
__ZN18MSCoreAudioChannel18DoSetMicOnCallBackEv + 83 (in our app)
21 __ZN16CoreAudioManager5StartEv + 73 (in our app)
21 __ZN16CoreAudioManager9InitInputEv +
4969 (in our app
21 _AudioDeviceSetProperty + 287
21
__ZN9HALObject15SetPropertyDataERK26AudioObjectPropertyAddressmPKvmS4_PK14AudioTimeStamp
+ 225
21
__ZN9HALPlugIn21ObjectSetPropertyDataERK9HALObjectRK26AudioObjectPropertyAddressmPKvmS7_PK14AudioTimeStamp
+ 92
21
__Z39HP_HardwarePlugIn_ObjectSetPropertyDataPP28AudioHardwarePlugInInterfacemPK26AudioObjectPropertyAddressmPKvmS6_
+ 216
21
__ZN16IOA_SingleDevice15SetPropertyDataERK26AudioObjectPropertyAddressmPKvmS4_PK14AudioTimeStamp
+ 976
21
__ZN16IOA_SingleDevice19HogModeStateChangedEv + 45
21 _semaphore_wait_signal_trap + 10
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden