Leak from Nsurl and Avaudioplayer Using Arc

Leak from NSURL and AVAudioPlayer using ARC

Looks to be a leak in Apple's code... I tried using both

• -[AVAudioPlayer initWithData:error:] and
• -[AVAudioPlayer initWithContentsOfURL:error:]

In the first case, the allocated AVAudioPlayer instance retains the passed in NSData. In the second, the passed in NSURL is retained:

I've attached some screen shots of the Instruments window showing the retain/release history for a passed in NSData object.

You can see the AVAudioPlayer object then creates a C++ object AVAudioPlayerCpp, which retains the NSData again:

Later, when the AVAudioPlayer object is released, the NSData is released, but there's never a release call from the associated AVAudioPlayerCpp... (You can tell from the attached image)

Seems you'll have to use a different solution to play media if you want to avoid leaking NSData/NSURL's..

Here's my test code:

-(void)timerFired:(NSTimer*)timer
{
    NSString * path = [[ NSBundle mainBundle ] pathForResource:@"song" ofType:@"mp3" ] ;

    NSError * error = nil ;
    NSData * data = [ NSData dataWithContentsOfFile:path options:NSDataReadingMapped error:&error ] ;
    if ( !data )
    {
        if ( error ) { @throw error ; }
    }

    AVAudioPlayer * audioPlayer = data ? [[AVAudioPlayer alloc] initWithData:data error:&error ] : nil ;
    if ( !audioPlayer )
    {
        if ( error ) { @throw error ; }
    }

    if ( audioPlayer )
    {
        [audioPlayer play];
        [ NSThread sleepForTimeInterval:0.75 ] ;
        [ audioPlayer stop ] ;
    }
}

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    // ...
    [ NSTimer scheduledTimerWithTimeInterval:3.0 target:self selector:@selector( timerFired: ) userInfo:nil repeats:YES ] ;
    // ...
    return YES;
}

AVAudioPlayer preloaded sound leaks from memory

You should just disable ARC. When you enter backgroud, then if you don't use it it is being released. In Swift create AVAudioPlayer as Unmanaged<T> object.

How to solve leak in this Code (ARC enabled)?

I found the answer for the leak.

This leak is due to AVAudioPlayer foundation class which is yet to be fixed by Apple.

Thus Usage of AVAudioPlayer foundation class leads to leaks.

Check This link for more detail

NSPlaceholderString Memory Leak with ARC

I have received this kind of Leaks for NSPlaceholderString . But you can ignore that as it leaks because of Apple Framework and its of only 32 bytes .

AVAudioPlayer causing memory leak? Release memory?

You have proposed adding [file1Player release].

If you are using automatic reference counting, that is not only not necessary, but not permitted. If you are using manual reference counting, though, it is essential. But make sure to specify the delegate of the AVAudioPlayer or else that method won’t be called.

If you are using manual reference counting, I’d suggest using shift+command+B (or “Product” » “Analyze”) to perform static analysis. Especially in manual reference counting code (but even in ARC Objective-C code), this static analyzer is an extremely useful tool. There is no point in proceeding until you’ve resolved all issues identified there.

Or, as you suggest, even better, convert your manual reference counting project to automatic reference counting.

Instruments Memory Leak With ARC Confusion

Well, the leak is then probably originating somewhere from inside the framework (UIKit or deeper). If so, then there's not much you can do about it. Either it's some sort of "side effect" from inside your application that shows up later and deep inside UIKit ([UIImage imageWithCGImage:scale:orientation]), or it's some problem with UIKit itself. But in the end it's hard to tell for sure!

Using ARC still doesn't guarantee 100% memory-leak free code! ;)

Memory Leak - NSString & NSURL

Seems to be a memory leak in Core Foundation only in iOS 6.

Therefore filed as a bug:

Bug ID# 12699818.

Memory Leak - NSString & NSURL

Seems to be a memory leak in Core Foundation only in iOS 6.

Therefore filed as a bug:

Bug ID# 12699818.

---

Related Topics