I have been tracking down memory leaks in my iOS app and I keep coming back to the following code using the leaks instrument:
NSMutableArray *resultSet = [[NSMutableArray alloc] initWithCapacity:3];
NSAutoreleasePool *innerPool = [[NSAutoreleasePool alloc] init];
FMResultSet *rs = [db executeQuery:query,equipmentID];
while ([rs next])
{
[resultSet addObject: [rs resultDict]];
}
[rs close];
[innerPool release];
return [resultSet autorelease];
Is this the correct (in terms of memory management) usage of FMDB? Here is a screenshot of the leaks instrument:
leaks
Detailed Screenshot of the leak:
detail
Yes, this is correct memory management. The [rs close]; line is technically unnecessary, because it will happen (if it hasn't already) when the FMResultSet is deallocated (as part of the pool draining). But putting it in there explicitly is fine.
Is it possible you're over-retaining the return array?
SQLite allocates and keeps a bunch of memory, which is only freed when the database is closed. You can also adjust how much memory it will allocate by issuing a 'pragma cache_size = nnn' command.
See this related question and answer:
memory leak (?) after sqlite+fmdb vacuum command
Related
I have come across an issue when loading different NSImages repeatedly in an application written using Automatic Reference Counting. It seems as though ARC is not releasing the image objects correctly, and instead the memory usage increases as the list is iterated until the iteration is complete, at which point the memory is freed.
I am seeing up to 2GB of memory being used through the process in some cases. There's a good discussion on SO on a very similar issue which ends up putting the process in an NSAutoReleasePool and releasing the image and draining the pool. This works for me as well if I don't use ARC, but it is not possible to make calls to these objects / methods in ARC.
Is there any way to make this work in ARC as well? It seems as though ARC should be figuring this out all by itself - which makes me think that the fact that these objects are not getting released must be a bug is OS X. (I'm running Lion with XCode 4.2.1).
The kind of code which is causing the issue looks like this:
+(BOOL)checkImage:(NSURL *)imageURL
{
NSImage *img = [[NSImage alloc] initWithContentsOfURL:imageURL];
if (!img)
return NO;
// Do some processing
return YES;
}
This method is called repeatedly in a loop (for example, 300 times). Profiling the app, the memory usage continues to increase with 7.5MB alloced for each image. If ARC is not used, the following can be done (as suggested in this topic):
+(BOOL)checkImage:(NSURL *)imageURL
{
NSAutoReleasePool *apool = [[NSAutoReleasePool alloc] init];
NSImage *img = [[NSImage alloc] initWithContentsOfURL:imageURL];
if (!img)
return NO;
// Do some processing
[img release];
[apool drain];
return YES;
}
Does anyone know how to force ARC to do the memory cleaning? For the time being, I have put the function in a file which is compiled with -fno-objc-arc passed in as a compiler flag. This works OK, but it would be nice to have ARC do it for me.
use #autoreleasepool, like so:
+(BOOL)checkImage:(NSURL *)imageURL
{
#autoreleasepool { // << push a new pool on the autotrelease pool stack
NSImage *img = [[NSImage alloc] initWithContentsOfURL:imageURL];
if (!img) {
return NO;
}
// Do some processing
} // << pushed pool popped at scope exit
return YES;
}
I have a memory leak which crashes my App while copying / creating images width NSFileManager.
When i profile my App with "Allocations", everything looks fine. The Allocated Memory Goes up from aprox 1.5 MB to 6 MB during every recoursion and then drops to 1.5MB again.
But the "Real Memory" and "Virtuel Memory" grows to aprox 150MB and then the App crashes.
I receive Memory Warnings Level 1 and 2 before.
here is the function us use:
-(void) processCacheItems:(NSMutableArray*) originalFiles
{
if ( [originalFiles count] == 0 )
{
[originalFiles release];
return;
}
else
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSString *curFileName = [originalFiles lastObject];
NSString *filePath = [documentsDirectoryPath stringByAppendingPathComponent:curFileName];
NSURL *fileURL = [NSURL fileURLWithPath:filePath];
CGSize destinationSize = CGSizeMake(150,150);
CGSize previewDestinationSize = CGSizeMake(1440.0, 1440.0);
UIImage *originalImage = [UIImage imageWithContentsOfFile:filePath]; // AUTORELEASED
// create thumb and copy to presentationfiles directory
UIImage *thumb = [originalImage resizedImageWithContentMode:UIViewContentModeScaleAspectFit
bounds:destinationSize
interpolationQuality:kCGInterpolationHigh]; // AUTORELEASED
// the resizedImageWithContentMode: does not semm to make the problem, because when i skip this and just use the original file the same problem occours
NSString *thumbPath = [thumbsDirectoryPath stringByAppendingPathComponent:curFileName];
[fileManager createFileAtPath:thumbPath contents:UIImageJPEGRepresentation(thumb, 0.9) attributes:NULL];
// create thumb and copy to presentationfiles directory
UIImage *previewImage = [originalImage resizedImageWithContentMode:UIViewContentModeScaleAspectFit
bounds:previewDestinationSize
interpolationQuality:kCGInterpolationHigh]; // AUTORELEASED
NSString *previewImagePath = [previewsDirectoryPath stringByAppendingPathComponent:curFileName];
[fileManager createFileAtPath:previewImagePath contents:UIImageJPEGRepresentation(previewImage, 0.9) attributes:NULL];
// copy copy original to presentationfiles directory
NSString *originalPath = [originalFilesDirectoryPath stringByAppendingPathComponent:curFileName];
[fileManager copyItemAtPath:filePath toPath:originalPath error:NULL];
[originalFiles removeLastObject];
[pool drain];
[self processCacheItems:originalFiles]; // recursion
}
}
Thank you for your Hint.
I fond out, that the Problem was not a leak, but the memory Allocation was too big when scaling down Big Images in "resizedImageWithContentMode:" That made the App crash.
I changed the Image scaling to use the Image I/O framework.
Now it works fine.
UPDATE: This answer is outdated. If you are using ARC, ignore it .
How do you allocate NSFileManager?
I have experienced that allocating it via the + defaultManager method, which is deprecated, produces memory leaks (or Instruments says so, Instruments sometimes reports memory leaks where there are not).
Generally, you should allocate it with [[NSFileManager alloc] init] and release when you no longer need it.
I have a memory leak in my iPhone app. I added Google AdMob to my app using sample code downloaded from Google. However, I was having a hard time getting it into testing mode so I added an extra variable as follows:
GADRequest *r = [[GADRequest alloc] init];
r.testing = YES;
[bannerView_ loadRequest:r];
I found the memory leak using Instruments. Instruments does not lead me to this line of code, it just dumps me in the main.m file. However, when I comment out the code relating to AdMob the leak goes away and I know enough to see that I haven't taken care of releasing this new variable. I just don't know exactly how I should set about releasing it. The variable r is not addressed in the header file so this is all the code that deals with it.
I tried adding:
- (void)dealloc {
[r release];
....
}
but that caused a build error saying "'r' undeclared". That's weird because it looks to me like I'm declaring r in the first quoted line above but I guess that's wrong. Any help would be much appreciated. I really have tried to educate myself about memory leaks but I still find them very confusing.
Just add [r release]; right below the code:
GADRequest *r = [[GADRequest alloc] init];
r.testing = YES;
[bannerView_ loadRequest:r];
[r release];
The variable r is declared only in that section of your code, so that's where it should be released. The point of releasing is to get rid of it as soon as you no longer need it, so the above should work perfectly for you.
If your r is locally declared (as it seems, judging from your snippet), then it cannot be accessed from outside its scope (here: the method it was declared in).
You either need to make it accessible within your class instance by declaring it an ivar.
Declaring it an ivar would look like this:
#interface YourClass : SuperClass {
GADRequest *request;
}
//...
#end
You then change your code to this:
request = [[GADRequest alloc] init];
request.testing = YES;
[bannerView_ loadRequest:request];
Also don't forget to release it in dealloc:
- (void)dealloc {
[request release];
//...
}
However this is not what you want in this situation (I've just included it to clarify why you get the warning about r not being declared).
You (most likely) won't need request any second time after your snippet has run, thus storing it in an ivar will only needlessly occupy RAM and add unwantd complexity to your class. Stuff you only need at the immediate time after its creation should be taken care of (released) accordingly, that is within the very same scope.
What you'll actually want to do is simply (auto)release it, properly taking care of it.
Keep in mind though that your loadRequest: will need to take care of retaining r for as long as it needs it. Apple's implementation does this, of course. But you might want to write a similar method on your own one day, so keep this in mind then.
GADRequest *r = [[GADRequest alloc] init];
r.testing = YES;
[bannerView_ loadRequest:r];
[r release]; //or: [r autorelease];
OP here. Thanks for all the detailed and thoughtful responses. This has definitely helped get a better handle on memory management. I did exactly as recommended, adding [r release]; right below the posted code. However, I still have a leak. I have isolated it to a single line of code. The following leaks:
GADRequest *r = [[GADRequest alloc] init];
r.testing = YES;
[bannerView_ loadRequest:r];
[r release];
The following does not leak:
GADRequest *r = [[GADRequest alloc] init];
r.testing = YES;
// [bannerView_ loadRequest:r];
[r release];
I figure I'm changing the retain count on bannerView with the loadRequest but I don't know how to fix it. I tried a [bannerView_ release] immediately after the [r release]; line (i.e. releasing locally) but that didn't work. I didn't expect it to because bannerView_ is declared elsewhere. I tried [bannerView_ release]; in the dealloc method but that didn't work. I also tried [bannerView_ autorelease]; locally. The wise heads at Google put [bannerView_ release]; in the ViewDidUnload method.
It's possible that Instruments is just messing with my head. The leak appears after about 10 seconds but the app performs well and the amount of memory leaked doesn't seem to be spirally upwards as the app continues to run. Is there such a thing as a benign memory leak?
Thanks again for your help,
Dessie.
Here is a sample code, i am trying to import contacts for the iphone to my app.
-(IBAction)import_Clicked:(id)sender{
ABPeoplePickerNavigationController *picker = [[ABPeoplePickerNavigationController alloc] init]; //leaking here
picker.peoplePickerDelegate = self;
// Display only a person's phone, email, and birthdate
NSArray *displayedItems = [NSArray arrayWithObjects:[NSNumber numberWithInt:kABPersonPhoneProperty],
[NSNumber numberWithInt:kABPersonEmailProperty],
[NSNumber numberWithInt:kABPersonBirthdayProperty], nil];
picker.displayedProperties = displayedItems;
[self presentModalViewController:picker animated:YES];
[picker release];}
i ran this on instruments and it shows me 100% leak at line where i alloc abpeoplepickernavigationcontroller. i realsed it after persentmodalviewcontroller. where else could i go wrong.
Any Help , Please.....
There seems to be a strange SDK bug at large here... Have a read of the official Apple dev forums here for more information and a solution.
Strange, that doesn't looks like a leak to me, heard that Instruments (rarely) report false leaks.
EDIT: forget what follows and read bbum comment instead :)
Could you please try removing [picker release] and then use autorelease instead :
BPeoplePickerNavigationController *picker = [[[ABPeoplePickerNavigationController alloc] init] autorelease];
Then see if instruments still report a leak? If not, keep your original code and ignore that false alert...
That is almost the same but using NSAutoReleasePool might change Instruments behavior.
Please also note that explicitly releasing like you did is a more cleaner approach than autoreleasing.
I have an application that runs in the background only (by specifying LSBackgroundOnly in the info.plist file).
The problem is, that all blocks that I run on parallel queues are not being released.
The code is executed in a memory-managed environment - no GC is involved.
The (simplified) code looks like below. Blubber is just some dummy class that holds an NSDate for testing. Also, it overwrites retain, release, and dealloc to do some logging:
NSOperationQueue *concurrentQueue = [[NSOperationQueue alloc] init];
[concurrentQueue setMaxConcurrentOperationCount:NSOperationQueueDefaultMaxConcurrentOperationCount];
Blubber *aBlubber = [[Blubber alloc] init];
aBlubber.aDate = [NSDate date];
[concurrentQueue addOperationWithBlock:^{
NSAutoreleasePool *blockPool = [[NSAutoreleasePool alloc] init];
NSDate *test = [aBlubber aDate];
NSLog(#"Block DONE");
[blockPool release];
}];
[aBlubber release];
[concurrentQueue release];
If I change the application to be a normal (i.e. non-backgound) application, I can observe the blocks being released whenever any input is made via the UI (even changing the focus to another window is sufficient).
Since my backgorund app receives input directly over the HID USB driver and it does not have a window or menu bar this does not happen.
Is there any way to manually force the runloop or whatever is responsible to telling the queues to release the finished blocks?
(All other objects that had been retained by the blocks are also not released, creating huge memory leaks. These leaks cannot be spottet by the Leaks or ObjectAllocations tools but the memory consumption can be observed skyrocketing using top.)
One common "gotcha" for autorelease pools is that if the app is building up memory without receiving events, the outermost pool (the one managed by the event loop) won't be draining.
I don't think that should apply here since you're managing your own pool... but just in case, you could try this:
...
//When no events are coming in (i.e. the user is away from their computer), the runloop doesn't iterate, and we accumulate autoreleased objects
[[NSTimer scheduledTimerWithTimeInterval:60.0f target:self selector:#selector(kickRunLoop:) userInfo:nil repeats:YES] retain];
...
- (void) kickRunLoop:(NSTimer *)dummy
{
// Send a fake event to wake the loop up.
[NSApp postEvent:[NSEvent otherEventWithType:NSApplicationDefined
location:NSMakePoint(0,0)
modifierFlags:0
timestamp:0
windowNumber:0
context:NULL
subtype:0
data1:0
data2:0]
atStart:NO];
}
It looks like you are using a stack based block that is used after the block has gone out of scope. The block needs to be copied. The code should work if it is changed to this:
[concurrentQueue addOperationWithBlock:[[^{
NSAutoreleasePool *blockPool = [[NSAutoreleasePool alloc] init];
NSDate *test = [aBlubber aDate];
NSLog(#"Block DONE");
[blockPool release];
}copy]autorelease]];
Take a look at this post for a full writeup on blocks: http://gkoreman.com/blog/2011/02/27/blocks-in-c-and-objective-c/