I'm pretty sure this is causing a leak and I would like some advice. Here's code based on what I'm doing:
NSMutableArray* straVideoTitles;
- (void) parseData{
//stuff
straVideoTitles = [self getVideoTitle:strData]; //strData contains unparsed data
//more stuff
}
- (NSMutableArray*) getVideoTitles:(NSString*)strData{
NSMutableArray *array;
array = [[NSMutableArray alloc] init];
//Parse data and populate array
return array;
}
Based on the fact that I'm allocating space for NSMutableArray and not releasing it, thats a leak right? How do I tackle this? Should I forgo returning a value and assign straVideoTitles inside getVideoTitles then release like:
- (void) getVideoTitles:(NSString*)strData{
NSMutableArray *array;
array = [[NSMutableArray alloc] init];
//Parse data and populate array
straVideoTitles = array;
[array release];
}
or am i going about this all wrong? Or is everything fine because I'm releasing straVideoTitles in dalloc?
You could change the
return array;
into
return [array autorelease];
Or you could use ARC and just don't care about it anymore.
Edit: The second approach is possible and does not include a memory leak but the code is less capsulated and therefore less reusable and future prove.
Change to
return [array autorelease];
It is good practice to return autorelease objects from methods. This is called a deferred release message.
You are relinquishing ownership while allowing the caller of the method to use the returned array before it is deallocated.
Your return statement should read:
return [array autorelease];
For more information on memory management take a look here:
Advanced Memory Management Programming Guide
Related
Here is code I am referring to.
// Person.h
#interface Person : NSObject {
NSString *firstName;
NSString *lastName;
}
#end
// Person.m
#implementation Person
- (id)init {
if (![super init]) return nil;
firstName = #"John";
lastName = #"Doe";
}
#end
// MyClass.m
#implementation MyClass
.....
- (NSArray *)getPeople {
NSMutableArray *array = [[NSMutableArray alloc] init];
int i;
for (i = 0; i < 10; i++) {
Person *p = [[Person alloc] init];
[array addObject:p];
}
return array;
}
.....
#end
Now, I know there is no memory-management going on in this sample code. What would be required?
In the getPeople loop, I am alloc'ing a Person (retainCount 1), then adding it to array. The retain count is now 2, right? If it is two, should I be [p release]'ing after adding it to the array, bringing the retainCount back down to 1?
Am I right in that it is the caller's responsibility to release the array returned by the method? (Which would also free the memory of the Person's, and their instance variables, assuming their counts are at 1).
I have read Apple's memory management document, but I guess what I am most unclear about, is what increases an objects retain count? I think I grasp the idea of who's responsibility it is to release, though. This is the fundamental rule, according to Apple:
You take ownership of an object if you create it using a method whose name begins with “alloc” or “new” or contains “copy” (for example, alloc, newObject, or mutableCopy), or if you send it a retain message. You are responsible for relinquishing ownership of objects you own using release or autorelease. Any other time you receive an object, you must not release it.
bobDevil's sentence "only worry about the retain counts you add to the item explicitly" made it click for me. After reading the Ownership policy at Apple, essentially, the object/method that created the new object, is the one responsible for releasing /it's/ interest in it. Is this correct?
Now, let's say I a method, that receives an object, and assigns it to a instance variable. I need to retain the received object correct, as I still have an interest in it?
If any of this is incorrect, let me know.
You are correct that the retain count is 2 after adding it to an array. However, you should only worry about the retain counts you add to the item explicitly.
Retaining an object is a contract that says "I'm not done with you, don't go away." A basic rule of thumb (there are exceptions, but they are usually documented) is that you own the object when you alloc an object, or create a copy. This means you're given the object with a retain count of 1(not autoreleased). In those two cases, you should release it when you are done. Additionally, if you ever explicitly retain an object, you must release it.
So, to be specific to your example, when you create the Person, you have one retain count on it. You add it to an array (which does whatever with it, you don't care) and then you're done with the Person, so you release it:
Person *p = [[Person alloc] init]; //retain 1, for you
[array addObject:p]; //array deals with p however it wants
[p release]; //you're done, so release it
Also, as I said above, you only own the object during alloc or copy generally, so to be consistent with that on the other side of things, you should return the array autoreleased, so that the caller of the getPeople method does not own it.
return [array autorelease];
Edit:
Correct, if you create it, you must release it. If you invest interest in it (through retain) you must release it.
Retain counts are increased when you call alloc specifically, so you'll need to release that explicitly.
factory methods usually give you an autoreleased object (such as [NSMutableArray array] -- you would have to specifically retain this to keep it around for any length of time.).
As far as NSArray and NSMutableArray addObject:, someone else will have to comment. I believe that you treat a classes as black boxes in terms of how they handle their own memory management as a design pattern, so you would never explicitly release something that you have passed into NSArray. When it gets destroyed, its supposed to handle decrementing the retain count itself.
You can also get a somewhat implicit retain if you declare your ivars as properties like #property (retain) suchAndSuchIvar, and use #synthesize in your implementation. Synthesize basically creates setters and getters for you, and if you call out (retain) specifically, the setter is going to retain the object passed in to it. Its not always immediately obvious, because the setters can be structured like this:
Person fart = [[Person alloc] init];
fart.firstName = #"Josh"; // this is actually a setter, not accessing the ivar
// equivalent to [fart setFirstName: #"Josh"], such that
// retainCount++
Edit:
And as far as the memory management, as soon as you add the object to the array, you're done with it... so:
for (i = 0; i < 10; i++) {
Person *p = [[Person alloc] init];
[array addObject:p];
[p release];
}
Josh
You should generally /not/ be worried about the retain count. That's internally implemented. You should only care about whether you want to "own" an object by retaining it. In the code above, the array should own the object, not you (outside of the loop you don't even have reference to it except through the array). Because you own [[Person alloc] init], you then have to release it.
Thus
Person *p = [[Person alloc] init];
[array addObject:p];
[p release];
Also, the caller of "getPeople" should not own the array. This is the convention. You should autorelease it first.
NSMutableArray *array = [[[NSMutableArray alloc] init] autorelease];
You'll want to read Apple's documentation on memory management: http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html
I am trying to select multiple UITableViewCells, it is working fine, but I can't add strings to my NSMutableArray.
I am using this code, and my log always is (null):
self.mutarray = [[NSMutableArray alloc] init];
[self.mutarray addObject:path]; //path is an NSString
NSLog(#"%#", self.mutarray);
It must add the path of the UITableViewCell to the NSMutableArray, is that even possible?
Oh, and I am calling this in - (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
As per your comments "it shows only the new added string, but not all strings.". This is because you are allocating NSMutable Array in the delegate method of table view. Everytime you hit the cell a new array is get allocated.
Either allocate your "mutarray" array in ViewDidLoad
Or
Only allocate it if it is nil or empty.
if(!self.mutarray)
self.mutarray = [[NSMutableArray alloc] init];
It seems that you haven't initialized your array. A good practice for properties is using something called lazy initialization.
Add this method.
- (NSMutableArray *)mutarray
{
if (!_mutarray) {
_mutarray = [[NSMutableArray alloc] init];
}
return _mutarray;
}
So every time you request the array, the accessor will make sure that the object is created before returning it. This is a good way of defensive programming.
You have to alloc/init before adding any objects:
if(!mutarray)mutarray = [[NSMutableArray alloc]init];
[self.mutarray addObject:path];
Have you tried to add a copy of the path?
Since UITableViewCells are resused, maybe the problem resides to this?
[self.mutarray addObject:[path copy]];
Suppose in my Database Manager which is singleton.
+ (SWDatabaseManager *)retrieveManager
{
#synchronized(self)
{
if (!sharedSingleton)
{
sharedSingleton = [[SWDatabaseManager alloc] init];
}
return sharedSingleton;
}
}
- (NSArray *)getProductDetails:(NSString *)someString
{
NSArray *temp = [self getRowsForQuery:someString];
return temp;
}
- (NSArray *)getRowsForQuery:(NSString *)sql
{
sqlite3_stmt *statement=nil;
NSMutableArray *arrayResults = [NSMutableArray arrayWithCapacity:1];
//
//Fetching data from database and adds them in to arrayResults
//
return arrayResults;
}
Now from some view controller i am calling function of Database manager like this....
[self getProductServiceDidGetDetail:[[SWDatabaseManager retrieveManager] getProductDetail: #"SomeQuery"]
- (void)getProductServiceDidGetDetail:(NSArray *)detailArray
{
[self setDataSource:[NSArray arrayWithArray:detailArray]];
[self.tableView reloadData];
}
Questions are ...
When arrayResult of getRowsForQuery will release?
Do i need to assign nil to detailArray of getProductServiceDidGetDetail?
Is there any memory leaks?
Suggestion will be appreciated.
ARC does automatic memory management. So it releases everything (your array), when you are done using it.
ARC works by adding code at compile time to ensure that objects live
as long as necessary, but no longer. Conceptually, it follows the same
memory management conventions as manual reference counting (described
in Advanced Memory Management Programming Guide) by adding the
appropriate memory management calls for you.
To help you understand better you might want to read apples docs on ARC.
You will not need to assign nil to the array, nor do you have to worry about memory leaks.
You do not have to (indeed cannot) release instance variables, but you
may need to invoke [self setDelegate:nil] on system classes and other
code that isn’t compiled using ARC.
NSMutableArray * arrayTest;
-(void) setContent
{
//must I call [array removeAllObjects]; ?
arrayTest = [[NSMutableArray alloc] init]
[arrayTest addObject:#"str"];
...//add many objects
}
I call this function at different code snippet. do I need to removeAllObjects of arrayTest before , then alloc memory for arrayTest every time ? I use ARC .
I don't want my app memory to increase every time I call this function.
No, what you have is fine. You don't need to call removeAllObjects under ARC or non-ARC.
When the old array is deallocated, it will take care of releasing all of the objects in the old array.
Check if arrayTest exists before alloc'ing memory. If you don't you'll have a new array every time the method is called (assuming you want to keep the array and it's content around for a while). Or even better.. move the alloc into the init of the class.
-(void) setContent
{
if(!arrayTest){
arrayTest = [[NSMutableArray alloc] init];
}
[arrayTest addObject:#"str"];
...//add many objects
}
I must have misunderstood some of the memory management rules, because when I try to fix a memory leak, the App crashes. Let me show you some code:
calendarRequestLog is a property of type MutableDictionary in a singleton object, that exists as long as the App runs. Here's the declaration in the .h file:
#property (nonatomic, retain, readonly) NSMutableDictionary *calendarRequestLog;
I allocate it with (in init):
calendarRequestLog = [[NSMutableDictionary alloc] init];
I fill it with this (notice the retain, that creates the memory leak):
[calendarRequestLog setObject:[[NSMutableArray arrayWithObject:delegate] retain] forKey:date];
I sometimes access it with this:
NSMutableArray* delegates = [calendarRequestLog objectForKey:date];
if(delegates != nil) {
// add delegates
}
I empty it with this:
NSMutableArray* delegates = [calendarRequestLog objectForKey:date];
if(delegates != nil) {
for (id <ServerCallDelegate> delegate in delegates) { … }
// clear the request from the log
[calendarRequestLog removeObjectForKey:date];
}
Here's the code that crashes when I remove the retain above:
NSMutableArray* delegates = [calendarRequestLog objectForKey:date];
if(delegates != nil) {
if([delegates containsObject:delegate]) // crash
[delegates removeObject:delegate];
}
It crashes because delegates is deallocated but not nil. To be more precise, I get an EXC_BAD_ACCESS Exception.
All these methods may be called in different orders or multiple times.
I cannot figure out, why this happens. I thought, collections are supposed to retain their objects - as this array-object (delegates) is still in the collection, it should not be deallocated. Other code cannot be responsible, I showed you all occurrences of calendarRequestLog.
I appreciate all the help I can get!
#Edit
I think I got it.
I call the crashing method when the delegate gets deallocated, so that I do not call the delegate per accident later.
But: I retain the delegates in my calendarRequestLog, so it cannot get deallocated as long as this doesn't get called:
// clear the request from the log
[calendarRequestLog removeObjectForKey:date];
...which in turn, deallocates the delegate and calls the crashing method. As the calendarRequestLog has removed the delegates, but not yet the key, we crash.
Ok, I will solve this differently. Thanks for all the comments - thanks to you, I looked elsewhere!
Did you try retaining when fetching so nobody releases your object while you're using it?
NSMutableArray* delegates = [[calendarRequestLog objectForKey:date] retain];
if(delegates != nil) {
if([delegates containsObject:delegate]) // crash
[delegates removeObject:delegate];
}
[delegates release];
Common practice is the following, because you already retain in the .h file:
//create local instance, then copy that to the class wide var
NSMutableDictionary *_calendarRequestLog = [NSMutableDictionary alloc] init];
self.calendarRequestLog = _calendarRequestLog;
[_calendarRequestLog release];
Also, I don't really understand why you would retain here:
[calendarRequestLog setObject:[[NSMutableArray arrayWithObject:delegate] retain] forKey:date];
Why not just change that to:
[calendarRequestLog setObject:[NSMutableArray arrayWithObject:delegate] forKey:date];
Write instead
calendarRequestLog = [[NSMutableDictionary alloc] init];
this
self.calendarRequestLog = [NSMutableDictionary dictionary];
and try to use property instead ivar