Re: AudioDeviceStop and ioProc
Re: AudioDeviceStop and ioProc
- Subject: Re: AudioDeviceStop and ioProc
- From: Steve Checkoway <email@hidden>
- Date: Mon, 22 May 2006 22:34:54 -0700
On May 22, 2006, at 12:53 PM, Jeff Moore wrote:
Technically, these look like backtraces generated by gdb.
Thank you! I put a lot of work into getting a getting a readable
backtrace (among other pieces of info) in crash conditions. In this
case, I have the app set to dump all of the threads' stack traces
when it receives SIGUSR1.
This will give you a very limited view on the hang. The sample tool
gives a more complete picture because it samples the backtraces of
all the threads in the process repeatedly over time to generate a
histogram. The net result is that it is generally much clearer as
to which threads are actually hung and which are just in the middle
of a system call or something like that.
I've never used it before and when I tried it just now I got:
Host Name: DualG5
Date/Time: 2006-05-22 21:58:50.096 -0700
OS Version: 10.4.6 (Build 8I127)
Report Version: 4
Command: Sampler
Path: /Developer/Applications/Performance Tools/Sampler.app/
Contents/MacOS/Sampler
Parent: WindowServer [70]
Version: 2.0.2 (2.0.2)
PID: 2223
Thread: Unknown
Link (dyld) error:
Library not loaded: /System/Library/PrivateFrameworks/
Graphite.framework/Versions/A/Graphite
Referenced from: /Developer/Applications/Performance Tools/
Sampler.app/Contents/MacOS/Sampler
Reason: image not found
(Yes, I do realize that my computer's name is not imaginative.)
[...]
This backtrace looks odd. It definitely doesn't look like an IO
thread usually looks. There are all sorts of stack frames missing.
Either this isn't the IO thread or gdb stopped at a time where the
thread's stack was in a strange state.
That wasn't gdb but my own stack trace code.
For what it's worth, here's what gdb has to say in the case where I
change the sample rate and then try to quit:
^C
Program received signal SIGINT, Interrupt.
0x9000b0a8 in mach_msg_trap ()
(gdb) thread 2
[Switching to thread 2 (process 2303 thread 0x3503)]
#0 0x9002c128 in semaphore_wait_signal_trap ()
(gdb) bt
#0 0x9002c128 in semaphore_wait_signal_trap ()
#1 0x90001990 in pthread_mutex_lock ()
#2 0x91479508 in CAMutex::Lock ()
#3 0x914939ec in IOA_Device::StartCommandExecution ()
#4 0x91493824 in HP_Device::ExecuteCommand ()
#5 0x9149fb14 in HP_PlugIn_DeviceStop ()
#6 0x9149fa50 in HALPlugIn::DeviceStopIOProc ()
#7 0x9149f9b4 in AudioDeviceStop ()
#8 0x001630dc in RageSound_CA::~RageSound_CA (this=<incomplete
type>, __in_chrg=3) at /Users/steve/programming/stepmania/src/arch/
Sound/RageSoundDriver_CA.cpp:429
#9 0x0016301c in RageSound_CA::~RageSound_CA (this=<incomplete
type>) at /Users/steve/programming/stepmania/src/arch/Sound/
RageSoundDriver_CA.cpp:417
#10 0x0001ab60 in RageSoundManager::Shutdown (this=<incomplete type>)
at /Users/steve/programming/stepmania/src/RageSoundManager.cpp:85
#11 0x00055b78 in ShutdownGame () at /Users/steve/programming/
stepmania/src/StepMania.cpp:247
#12 0x00058560 in SM_main (argc=1, argv=0xbffff11c) at /Users/steve/
programming/stepmania/src/StepMania.cpp:1123
#13 0x00258f8c in -[SMMain startGame:] (self=0x7e20da0,
_cmd=0x313674, sender=0x0) at /Users/steve/programming/stepmania/src/
archutils/Darwin/SMMain.mm:57
#14 0x92976194 in forkThreadForFunction ()
#15 0x9002ba68 in _pthread_body ()
(gdb) thread 3
[Switching to thread 3 (process 2303 thread 0x6a03)]
#0 0x9002c128 in semaphore_wait_signal_trap ()
(gdb) bt
#0 0x9002c128 in semaphore_wait_signal_trap ()
#1 0x90030bec in pthread_cond_wait ()
#2 0x9148c6f0 in CAGuard::Wait ()
#3 0x91494364 in IOA_Device::StopIOEngine ()
#4 0x914c3bf0 in IOA_SingleDevice::HWDevice_Paused ()
#5 0x9149b1fc in IOA_HWDevice::MachPortCallBack ()
#6 0x907f1820 in __CFMachPortPerform ()
#7 0x907f1734 in __CFRunLoopDoSource1 ()
#8 0x907e3e4c in __CFRunLoopRun ()
#9 0x907e347c in CFRunLoopRunSpecific ()
#10 0x9148c83c in HALRunLoop::OwnThread ()
#11 0x9148c5dc in CAPThread::Entry ()
#12 0x9002ba68 in _pthread_body ()
(gdb) thread 5
[Switching to thread 5 (process 2303 thread 0xb403)]
#0 0x9002c1a8 in swtch_pri ()
(gdb) bt
#0 0x9002c1a8 in swtch_pri ()
#1 0x9004b644 in pthread_mach_thread_np ()
#2 0x9148c674 in CAPThread::SetPriority ()
#3 0x9149bcb0 in HP_IOThread::WorkLoop ()
#4 0x9149b75c in HP_IOThread::ThreadEntry ()
#5 0x9148c5dc in CAPThread::Entry ()
#6 0x9002ba68 in _pthread_body ()
I can continue and then backtrace these threads again with the exact
same result (over and over).
In the other case where I don't change the sample rate, I get a crash
in thread 5, this time thread 2 isn't blocked as it was before and
the HAL's two threads look like
(gdb) thread 3
[Switching to thread 3 (process 2327 thread 0x6a03)]
#0 0x9000b0a8 in mach_msg_trap ()
(gdb) bt
#0 0x9000b0a8 in mach_msg_trap ()
#1 0x9000affc in mach_msg ()
#2 0x907e3b78 in __CFRunLoopRun ()
#3 0x907e347c in CFRunLoopRunSpecific ()
#4 0x9148c83c in HALRunLoop::OwnThread ()
#5 0x9148c5dc in CAPThread::Entry ()
#6 0x9002ba68 in _pthread_body ()
(gdb) thread 5
[Switching to thread 5 (process 2327 thread 0xb403)]
#0 0x9002ba7c in _pthread_body ()
(gdb) bt
#0 0x9002ba7c in _pthread_body ()
All of the other (non-sleeping) threads continue to make progress.
I'm at a bit of a loss as to why this is happening. I'm going to
reinstall the dev tools to see if I can get Sampler to work. If
nothing else, I can go back to my noncrashing code and try to make
incremental changes toward this code and see if I can figure out
where things go horribly wrong.
- Steve
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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