Here is the statement and the potential problem reported after Analyzing:
else { NSURL *buttonSound = [[NSBundle mainBundle] URLForResource: @"MachineClick" withExtension: @"wav"]; self.buttonSoundFileURLRef = (__bridge_retained CFURLRef) buttonSound; AudioServicesCreateSystemSoundID (buttonSoundFileURLRef_,&buttonSoundFileObject_); }
Potential leak of an object allocated on line 791 and stored into 'buttonSound' Method returns an Objective-C object with a +0 retain count Reference count incremented. The object now has a +1 retain count Object leaked: object allocated and stored into 'buttonSound' is not referenced later in this execution path and has a retain count of +1
Of course it "isn't referenced later in this execution path," because the sound object is just hanging around waiting to be used if needed later on. I don't create and destroy the sound on demand, I create it once and use it perhaps many times (or not at all).
And, I have these in dealloc().
AudioServicesDisposeSystemSoundID (buttonSoundFileObject_); CFRelease (buttonSoundFileURLRef_);
Although since I updated the app to ARC a long time ago, as I recall the CFRelease wasn't needed and actually resulted in an error (I had it commented out to make it work) and the compiler now for some reason doesn't mind it being there. So I doubt that actually matters when using ARC.
However, perhaps if the user goes back and changes the prefs, which results in the sounds being set again, this would increment the reference count. I was worried about that before and checked to see if the reference existed and if it did to release them, but that wouldn't compile for some reason. It's been awhile. Maybe I should probably try that again.
As it turns out most of the warnings are red herrings because they exist in a sequence of if else statements and only one is executed any time the setSounds method is run.
There was no error of any kind reported anywhere in the code before updating to 4.3.1:
Phil...
On Sep 16, 2012, at 15:45 , Philip McIntosh < email@hidden> wrote: AudioServicesCreateSystemSoundID (alertSoundFileURLRef_,&alertSoundFileObject_);
It never had this problem before. These references are set when the app launches and checks to see which sound files to use for alerts depending on what preferences are set in the Settings app.
I have not loaded it on a device yet to run it in instruments, but is there a chance this is not a memory leak at all?
Since I don' think playing the sounds with AudioServicesPlaySystemSound (alertSoundFileObject_); increases the reference count I don't really see a problem with having the reference count set at 1 after the setAlertSounds method is run. True?
It's true that there's no "problem" with the reference count being 1 at some arbitrary point in its lifetime. The potential problem is that it's never released, which depends on code you haven't quoted here. You've assumed ownership of the sound object you create, and presumably the analyzer is telling you that it can't see where you've relinquished ownership. You'll have to show more code to get an opinion on whether the warning is a false positive.
************ I would bet the problem is that you don't manage the lifetime of the audioSoundFileURLRef_, and the analyzer pointed to that line because it was the last reference to it in the code, not because it was the actual problem point. In general you are going to need to provide actual context to code like this before anyone can really help, since the single line of code doesn't provide enough context. -- David Duncan -------------- next part -------------- An HTML attachment was scrubbed... URL: < http://lists.apple.com/archives/xcode-users/attachments/20120917/9b512491/attachment.html> ------------------------------ _______________________________________________ Xcode-users mailing list email@hiddenhttps://lists.apple.com/mailman/listinfo/xcode-usersEnd of Xcode-users Digest, Vol 9, Issue 441 *******************************************
|