ExtAudioFileOpenUrl providing EXC_BAD_ACCESS

I created a sample application using the iPhone SDK that uses ExtAudioFileOpenURL from the AudioToolBox framework. I have a test file test.mp3 in my application document folder. When I tried to open this audio file using this API I got EXEC_BAD_ACCESS. I couldn't figure out why.

Here's a snippet of code:

NSArray *arr = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *str = [arr objectAtIndex:0];
NSString * temp = [NSString stringWithFormat:@"%@/test.mp3", str];
CFURLRef url = CFURLCreateWithFileSystemPath(kCFAllocatorDefault, (CFStringRef)temp, kCFURLPOSIXPathStyle, false);
//AudioFileID fileID ;
//AudioFileOpenURL(url, 0X01, kAudioFileCAFType, &fileID);
ExtAudioFileRef audioFileRef = NULL;
ExtAudioFileOpenURL(url, &audioFileRef);

      

I am getting EXC_BAD_ACCESS when I try ExtAudioFileOpenURL. I thought it was because of a bad url. But when I tried AudioFileOpenURL it worked great ensuring the url is valid.

0


source to share


1 answer


I wrote this to explain EXC_BAD_ACCESS

http://www.loufranco.com/blog/files/Understanding-EXC_BAD_ACCESS.html

Basically, you (possibly) either send messages to freed objects or corrupt the heap in some way. When a harmless call calls EXC_BAD_ACCESS, it almost always corrupts memory.



You never call release or dealloc in this code, so it is unlikely that this code can cause messages to be sent to freed objects.

So, maybe everything that calls EXC_BAD_ACCESS happened before this code. You can prove it by moving this code to the earliest time in your application - it will probably work. If not, then you really need to test this code, but if it works, then it's somewhere in between.

Probably the most efficient way to find corruption is using the Malloc Debug and then following the instructions on my blog to use the debugger to find the line that is causing the corrupted heap.

0


source







All Articles