writeImageToSavedPhotosAlbum leaks memory? - iphone

Question

Been having a tough time on this one, hope someone can help! New to posting, but have found this to be my go-to site for helping me through my apps.
I have an app that takes a CGImage and copies it to the Photo Library using writeImageToSavedPhotosAlbum:orientation:completionBlock:. Functionally works great, but Instruments seems to be telling me I have a leak. Through trial and error and commenting of code, I've found that this particular line is causing the leak:
[library writeImageToSavedPhotosAlbum:myCGImage
orientation:assetOrientation
completionBlock:^(NSURL *assetURL, NSError *error){
NSLog(#"image copied to album");
}];
That line seems innocuous enough to me, so I'm really not sure why it's causing a problem. Commented out, no leak. Leave it in, I see a leak!
Here's what Instrument shows in Leaked Blocks:
Leaked Object # Address Size Responsible Library Responsible Frame
GeneralBlock-36864, 0x8c77000 36.00 KB MusicLibrary MemNewPtrClear
Here's the stack trace from Instruments, which seems to imply it's related to the photo library indeed:
0 libsystem_c.dylib calloc
1 MusicLibrary MemNewPtrClear
2 MusicLibrary ReadITImageDB
3 MusicLibrary -[MLPhotoLibrary _loadImageLibrary]
4 MusicLibrary -[MLPhotoLibrary albums]
5 PhotoLibrary -[PLPhotoLibrary albums]
6 PhotoLibrary -[PLPhotoLibrary eventAlbumContainingPhoto:]
7 PhotoLibrary -[PLPhotoLibrary pictureWasTakenOrChanged]
8 PhotoLibrary __-[PLAssetsSaver queueJobData:requestEnqueuedBlock:completionBlock:imagePort:previewImagePort:]_block_invoke_2
9 libdispatch.dylib _dispatch_call_block_and_release
10 libdispatch.dylib _dispatch_main_queue_callback_4CF$VARIANT$up
11 CoreFoundation __CFRunLoopRun
12 CoreFoundation CFRunLoopRunSpecific
13 CoreFoundation CFRunLoopRunInMode
14 GraphicsServices GSEventRunModal
15 GraphicsServices GSEventRun
16 UIKit -[UIApplication _run]
17 UIKit UIApplicationMain
18 mogofoto main /Users/Jutsu/Documents/mogofoto2/main.m:14
19 mogofoto start
I do release myCGIImage later, and library as well, and assetOrientation is simply a ALAssetOrientation. Nothing else is custom code, so I'm stumped! (I'd be happy to post my other lines of code surrounding this if that may cause the problem).
Any help is hugely appreciated!!!

Answer 1

I had similar code to yours:
ALAssetsLibrary *library = [[ALAssetsLibrary alloc] init];
NSMutableDictionary *metadata = [[NSMutableDictionary alloc] init];
/* ... set up the metadata */
[library writeImageToSavedPhotosAlbum:image.CGImage metadata:metadata
completionBlock:^(NSURL *assetURL, NSError *error)
{ NSLog(#"assetURL %#", assetURL);
[metadata release];
[library release];
}
];
And I was seeing exactly the same leak as you:
Leaked Object Address Size Responsible Library Responsible Frame
GeneralBlock-36864,0x5066000 36.00 KB MusicLibrary MemNewPtrClear
GeneralBlock-36864,0x4fd3000 36.00 KB MusicLibrary MemNewPtrClear
GeneralBlock-36864,0x4f72000 36.00 KB MusicLibrary MemNewPtrClear
GeneralBlock-36864,0x45ce000 36.00 KB MusicLibrary MemNewPtrClear
with a stack:
0 libsystem_c.dylib calloc
1 MusicLibrary MemNewPtrClear
2 MusicLibrary ReadITImageDB
3 MusicLibrary -[MLPhotoLibrary _loadImageLibrary]
4 MusicLibrary -[MLPhotoLibrary albums]
5 PhotoLibrary -[PLPhotoLibrary albums]
6 PhotoLibrary -[PLPhotoLibrary eventAlbumContainingPhoto:]
7 PhotoLibrary -[PLPhotoLibrary pictureWasTakenOrChanged]
8 PhotoLibrary __-[PLAssetsSaver queueJobData:requestEnqueuedBlock:completionBlock:imagePort:previewImagePort:]_block_invoke_2
9 libdispatch.dylib _dispatch_call_block_and_release
10 libdispatch.dylib _dispatch_main_queue_callback_4CF$VARIANT$up
11 CoreFoundation __CFRunLoopRun
12 CoreFoundation CFRunLoopRunSpecific
13 CoreFoundation CFRunLoopRunInMode
14 GraphicsServices GSEventRunModal
15 GraphicsServices GSEventRun
16 UIKit -[UIApplication _run]
17 UIKit UIApplicationMain
18 myAppName main
19 myAppName start
I can't see anything wrong with the code, but on looking at it again it seemed stupid to be allocing the ALAssetsLibrary and the NSMutableDictionary every time I wanted to write an image. I re-wrote the code to keep hold of them, and removed the release calls from the completion block, and the leak has magically gone away.
I'm not sure if any of that actually helps you very much. But it does make me wonder if there isn't actually a problem in Apple's code, which is only getting triggered in certain circumstances -- certainly I wasn't seeing a leak for every image I was writing, only some of them.