Re: occasional crash in AudioQueueStop()
Re: occasional crash in AudioQueueStop()
- Subject: Re: occasional crash in AudioQueueStop()
- From: Christopher Liscio <email@hidden>
- Date: Fri, 17 Oct 2008 16:08:01 -0400
I'm not sure that's the best solution, Brian.
In the case you suggest, it would work provided the releasing of the
delegate (and the teardown of the callback) is done outside of the
dealloc call.
In my case, the delegate of the audio queue object in question owns a
reference to the audio queue object, and this retain strategy you
suggest would result in a retain cycle, since I tear down the callback
in the dealloc call (as most likely would).
It's common practice to not retain a delegate to avoid retain cycles
like this, and I try to stick to that as a general rule of thumb in my
code.
The retain 'fix' I proposed isn't meant to be slapped onto every call
to a delegate--only the calls made within CoreAudio callbacks that can
be invoked outside the main run loop.
Chris Liscio
http://SuperMegaUltraGroovy.com
Acoustic measurement software for Mac OS X -- http://www.FuzzMeasure.com
On Oct 17, 2008, at 3:09 PM, Brian Willoughby wrote:
Chris and others,
The suggested retain/release is the right solution in the wrong
place. You don't want to surround every single delegate call with a
retain and release. Instead, you want to call retain before you set
up your callback, to make sure that your delegate object lives as
long as your callback. Then, if you ever tear down your callback
(which is pretty unlikely if the callback lives for the duration of
your program), you should call release after the callback has been
successfully removed.
There are ways to make this a little easier by altering the way you
allocate and initialize your delegate object, but I won't get into
that here. Basically, I just wanted to touch on enough Cocoa to get
folks sorted for their CoreAudio callbacks.
Brian Willoughby
Sound Consulting
On Oct 17, 2008, at 09:38, Christopher Liscio wrote:
I recently fixed a problem like this myself.
Do you have a listener for the AudioQueue's start/stop notification
(it sounds like you do)? Furthermore, does it call into a cocoa
object to notify it of the start/stop status?
If you've answered yes to both of these questions, you might want to
investigate whether the cocoa object in question has 'disappeared'
between the point where you get a pointer to it, and the point where
you call the object.
The same could apply to a 'delegate' object or other method that you
call from within the callback.
The solution, in my case, was to retain the object before I called
it, and release it afterwards.
Seemingly innocuous code I fixed looked like this (paracoding):
id delegate = [queueObject delegate];
if ( [delegate respondsToSelector:@selector(queueDidStart:)] ) {
[delegate queueDidStart:queueObject];
}
The fixed code now looks like this:
id delegate = [[queueObject delegate] retain];
if ( [delegate respondsToSelector:@selector(queueDidStart:)] ) {
[delegate queueDidStart:queueObject];
}
[delegate release];
I struggled with this problem on and off for weeks (it kept
disappearing with other 'fixes', but reappearing again days later),
and it was a pain to debug.
Hope this helps,
Chris Liscio
On Oct 17, 2008, at 11:54 AM, John Zorko wrote:
My app is behaving much better, thanks in no small part to the help
of people on this list -- so thank you :-)
I still see an occasional crash, though ... and I don't know why.
Here's the last few frames of the backtrace:
[Switching to thread 10755]
Program received signal: “EXC_BAD_ACCESS”.
(gdb) bt
#0 0x3486df8c in ClientAudioQueue::ServicePendingCallbacks ()
#1 0x3486e314 in AudioQueueStop ()
#2 0x0000e7ee in -[AudioStreamer stop] (self=0x87da00,
_cmd=0x3018cc44) at /Users/jmzorko/devstuff/iphone/Magnatune/
Classes/AudioStreamer.m:381
#3 0x00008602 in -[AlbumController
tableView:cellForRowAtIndexPath:] (self=0x124b90, _cmd=0x30130e24,
tableView=0x1251e0, indexPath=0x131970) ...
The AudioStreamer -stop() method is simple:
- (void)stop
{
stopping = true;
if (connection)
{
[connection cancel];
NSLog(@"connection cancelled");
[connection release];
connection = nil;
if (started)
{
OSStatus err = AudioQueueStop(audioQueue, true);
if (err) { NSLog(@"AudioQueueStop"); return; }
}
else
{
self.isPlaying = false;
finished = true;
}
}
}
I am catching the _IsRunning notification, though I don't think the
issue is anything with that code. The AudioStreamer is based on
the AudioFileStreamExample project included with the developer
tools. Is this call stack indicative of something particular, some
common Core Audio n00b mistake?
_______________________________________________
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