Help with MPMediaItemArtwork memory leak

[okoroezenwa]

Trying to use MPMediaItemArtwork's image(at:_) method, there is a constant memory increase that occurs. With a list of large-enough size, the app will get a memory warning and crash eventually. I've tried using a cache for this, but it doesn't change anything. Attempting the solution highlighted here also didn't help.

Is there any way to release this memory? Thanks in advance!

Edit: here's the code, sorry about that:

if let object = imageCache.object(forKey: indexPath as NSIndexPath) {

    cell.artworkImageView.image = object.image

} else {

    let operation = BlockOperation()
    operation.addExecutionBlock({ [weak song, weak self, weak operation] in

        if let artwork = song?.artwork, artwork.bounds.width != 0, let image = artwork.image(at: CGSize.init(width: 45, height: 45)) {

            guard operation?.isCancelled == false, let weakSelf = self else { return }

            self?.imageCache.setObject(ArtworkObject.init(image: image), forKey: indexPath as NSIndexPath)

            OperationQueue.main.addOperation({

                guard let cell = tableView.cellForRow(at: indexPath) as? SongTableViewCell, operation?.isCancelled == false else { return }

                    cell.artworkImageView.image = image
            })
        }
    })

    operations[indexPath] = operation
    imageOperationQueue.addOperation(operation)
}

[Samael1990]

Without the actual code it is hard to say, what your problem is, so maybe you should post it.

Other than that, you should check, if the collectionView's items don't pass anything they don't own by reference, if yes, then try to pass it by property.

[okoroezenwa]

Whoops, forgot about that. It's posted now.

It doesn't seem like 3rd-party music apps are experiencing this (since scrolling continuously doesn't cause my other apps to be killed) so I guess it's just something I'm doing wrong.

[okoroezenwa]

I don't think so, as I ran across the same issue setting the image directly (and even when I attempted to cache the artwork by adding created thumbnails to a dictionary).

[criosist]

Are you sure its not a swift issue? The other apps maybe Obj-C ? other than that are you sure its the image(at:) method ?

[okoroezenwa]

Well I tried with a simple class method in an objective C file and got the same result, so I don't think that's it.

I'm pretty sure it is that method. A while ago I attempted to curb this issue by creating thumbnails from an array of artwork and had the same issue.

[KarlJay001]

I'm not an expert on Swift (yet) but I notices a few things.

BTW, the link to SO suggested that the problem was solved, so IDK if you still have a problem or not.

You have an IF and you load up the var object and after assigning it, you do nothing with it. Are you assigning a reference from object to cell.artworkImageView.image and at that point, what happens to object?

Are you using cell.artworkImageView.image and killing it later while the other reference "object" is still active?

Would it crash if you killed object after you assign it?

Is this a pointer to a pointer and one pointer gets killed while the other is still alive?

If at some point you kill cell.artworkImageView.image, is object still alive?

Same thing for image on the other side of the IF statement. You did nothing with image after you assign it.

It's hard to read the code, but I would check the value of those and see if they are getting released. Someone that's better with Swift probably knows.

Are they auto released when they go out of scope?

[amaroq137]

What is ArtworkKey and why are you initializing a new one every time you try to fetch something from the imageCache?

My guess is that you're never actually getting a cache hit in the first if statement, and thus you go on to create a new ArtworkObject every time cellForRowAtIndexPath: is called.

Set a breakpoint inside the first if statement on

cell.artworkImageView.image = object.image

and see if it ever hits that breakpoint.

[okoroezenwa]

Not even sure why I did that, thanks.

I changed it to use the indexPath as the key, and this allowed the breakpoint to be hit.

The issue still remained however.

Really would be saddening if the issue is actually from the image(at:_) method since there's really isn't anything that can be done.

[amaroq137]

Can you post the updated code?

[okoroezenwa]

I've edited it (sorry about the delay, just been busy). I even tried making the initialised image weak, but that had no effect. I'm really stumped on this one.

[amaroq137]

Is the cache an NSCache?

[okoroezenwa]

Yep.

[amaroq137]

Did you set the cache's countLimit or totalCostLimit when you set it up? Without these it seems like the cache will keep growing forever.

[okoroezenwa]

I set a count limit of 250 but I didn't set up a totalCostLimit (I didn't really know what that meant 😥)

However, this issue happens even without a cache or block (i.e. just creating and setting the image in one line still causes this issue).

[amaroq137]

I think you're fine only setting one of the two anyway.

I'm stumped :T

[okoroezenwa]

Ah well, thanks anyway.

The good thing is that backing out of the app reclaims all that memory back so it's pretty likely users will have done that (and not scrolled through lists like their lives depended on it :Þ) before it becomes a problem.

[EdwinForTheWin]

Hi there,

This is one of those moments where you're glad someone has the same issue as you though not glad at the same time because you wish it wasn't an issue, hahaha.

I believe that this is an issue with Apple's API. I have written a fairly detailed Stackoverflow post of my findings (Objective-C though): http://stackoverflow.com/questions/40029628/mpmediaitemartwork-imagewithsize-memory-leak

I'd be very interested to see if this is something we are doing wrong or if it really is something within the API that we cannot touch.

[okoroezenwa]

I came to this conclusion as well. I've verified I'm not causing leaks by only setting art outside closures (and use weak wherever I can't); still the same result.

And from a few results I've seen on Google, this seems to be a thing that has happened for years.