sample code:
- (Foo*)createFoo {
Foo *foo = [[Foo alloc] init];
return foo;
}
- (void)someOtherMethod {
Foo *foo;
foo = [self createFoo]; //retain count 1
[foo release]; //retain count = 0 => object gets released?
//repeat
foo = [self createFoo];
[foo release];
}
Question: Do i have to autorelease in createFoo or can i release the returned object in someOtherMethod?
Your code in this instance should be autoreleasing your object as you are handing over ownership to the calling code, you no longer wish to be responsible for it within the method and so you should relinquish your retain on it.
Remember NARC - methods that begin with these keywords are assumed to NOT autorelease...
New, Alloc, Retain, Copy
If your method were named newFoo or copyFoo then your code above would be fine without autoreleasing.
Cocoa memory management is actually quite easy because everybody sticks to a set of rules. You aren't following those rules, so you're going to run into trouble.
Read Basic Memory Management Rules. If you stick to following those rules, you should be fine.
Related
I have a non-ARC project that is using an ARC library. I am confused if I should release the object returned by the library method or not. Here is some example:
- (void)test{
LibObject* obj1 = [[LibObject alloc] init];
LibObject* obj2 = [obj1 otherObj];
[obj1 release]; //should I release it?
[obj2 release]; //should I release it?
}
Best to my knowledge, if the objects are in the autorelease pool, I should leave it alone. Otherwise, I should release it.
However, the ARC document says that
When returning from such a function or method, ARC retains the value at the point of evaluation of the return statement, then leaves all local scopes, and then balances out the retain while ensuring that the value lives across the call boundary. In the worst case, this may involve an autorelease, but callers must not assume that the value is actually in the autorelease pool.
Does the document imply that I should always release the object since I cannot assume the object is autoreleased?
See Memory Management Policy in the "Advanced Memory Management Programming Guide":
You own any object you create
You create an object using a method
whose name begins with “alloc”, “new”, “copy”, or “mutableCopy” (for
example, alloc, newObject, or mutableCopy).
You must not relinquish ownership of an object you do not own
These rules are consistent with methods compiled with ARC.
In the ARC documentation, the behaviour of methods in the first category is described in "3.2.2. Retained return values":
When returning from such a function or method, ARC retains the value
at the point of evaluation of the return statement, ...
which means that the caller must release the object.
Methods in the second category are described in "3.2.3. Unretained return values":
When returning from such a function or method, ARC retains the value
at the point of evaluation of the return statement, then leaves all
local scopes, and then balances out the retain ...
which means the the caller must not release the object.
So in your example:
LibObject* obj1 = [[LibObject alloc] init];
LibObject* obj2 = [obj1 otherObj];
[obj1 release]; //should I release it? --> YES
[obj2 release]; //should I release it? --> NO
You own obj1, because it was created with alloc, so you have to release obj1.
You don't own obj2, therefore you must not release it.
Note: If you run the Xcode static analyzer on your code, it shows exactly where these rules are violated.
When you get an object from ARC enabled class to your non-ARC enabled class you have the responsibility to manage the memory.
ARC just simply put retain, release in your ARC enabled code during compile time. It won't manage the memory on other classes or objects that is in non-ARC mode.
You should release such objects after your need.
My understanding is that if you use the compiler flag -fno-objc-arc for this file you need to take care of retain/release yourself. So you should call [obj1 release]. If you weren't supposed to call it yourself, the compiler would warn you accordingly.
With my understanding is that in your non-ARC code, you just do all the retain / release with ARC-enabled library as always (just like interacting with other non-ARC code).
I have created a simple app to prove this behaviour.
Testing Code - compiled without ARC
- (void)testARC
{
ARCLib *al = [[ARCLib alloc] init];
NSLog(#"%p retainCount = %u", al, [al retainCount]);
[al release];
ARCLib *al2 = [ARCLib arcLib];
NSLog(#"%p retainCount = %u", al2, [al2 retainCount]);
}
ARCLib - compiled with ARC
#implementation ARCLib
+ (id)arcLib
{
return [[self alloc] init];
}
- (id)init
{
self = [super init];
if (self)
{
NSLog(#"%p init",self);
}
return self;
}
- (void)dealloc
{
NSLog(#"%p dealloc",self);
}
#end
Result
2012-12-13 20:15:21.879 ARCTest[15206:907] 0x1e821500 init
2012-12-13 20:15:21.883 ARCTest[15206:907] 0x1e821500 retainCount = 1
2012-12-13 20:15:21.884 ARCTest[15206:907] 0x1e821500 dealloc
2012-12-13 20:15:21.885 ARCTest[15206:907] 0x1dd26060 init
2012-12-13 20:15:21.886 ARCTest[15206:907] 0x1dd26060 retainCount = 1
2012-12-13 20:15:21.893 ARCTest[15206:907] 0x1dd26060 dealloc
Answer to your question
You should release your obj1, but don't need to release obj2.
I'm currently developing an iOS application which was started by another developer.
Usually, I make a property for every instance variable (assign for int, bool etc. / retain for all classes).
So in my projects, this line causes a leak:
myVar = [[NSString alloc] init]; (alloc/init +1, retain in setter +1, release in dealloc -1 => +1)
So I use:
NSString *tmpMyVar = [[NSString alloc] init];
[self setMyVar: tmpMyVar];
[tmpMyVar release];
Or:
NSString *tmpMyVar = [[[NSString alloc] init] autorelease];
[self setMyVar: tmpMyVar];
In this new project, the previous developer didn't use #property/#synthesize so I'm wondering what will be the result of the previous line of code in this context (it doesn't call setter I guess)? Memory Leak?
The previous developer releases variable in dealloc method, just like me.
Thank you very much!
Since it directly assigns the instance variable to the allocated object it's retain count is 1 (because, like you said, a setter isn't called).
And because it's released in dealloc, it's all balanced out. So no memory leaks.
So in my projects, this line causes a leak:
myVar = [[NSString alloc] init]; (alloc/init +1, retain in setter +1, release in dealloc -1 => +1)
No,it wouldn't even in your projects, because, as you pointed out, no setter is used.
Also, when using properties, it is the recommended way to access instance variables directly in the init method, instead of using setters.
To inspect for questionable memory-leaks like your example, also use the clang static analyzer or instrument's leak tool.
You need to look at the other developer's setter implementation. Make sure they release the existing value and retain the new value; something like:
- (void)setMyString:(NSString *)string
{
[string retain];
[_string release]; // ivar
_string = string;
}
The only advantage to implementing your own setter/getter methods is to do something (other than setting the ivar) when a value is set. If the methods don't do anything like this then why not change all implementations to #property/#synthensize?
I am doing my project in xcode 4.2 (Older Version). For my application, I just set the variables, arrays in dto class for using in entire app lifecycle. so I set with a property like this.
AppDTO(sub class of NSObject)
AppDTO.h
#property(nonatomic,retain)anotherAppDTO *aAppDTO;
#property(nonatomic,retain)NSMutableArray *array1;
#property(nonatomic,retain)NSMutableArray *array2;
#property(nonatomic,retain)NSString *string1,*string2,*string3;
AppDTO.m
- (id)init
{
self = [super init];
if (self) {
self.aAppDTO = [[anotherAppDTO alloc]init];
self.array1 = [[NSMutableArray alloc]init];
self.array2 = [[NSMutableArray alloc]init];
self.string1 = #"Hello";
self.string2= #"Hai";
}
}
-(void)dealloc
{
if(array1 != nil)
{
[array1 release];
array1 = nil;
}
if(array2 != nil)
{
[array2 release];
array2 = nil;
}
[aAppDTO release];
aAppDTO = nil;
[super dealloc];
}
when I analyze my app in Xcode 4.3.2, I get memory warning in self.array1 and self.array2 (Potential leak on object allocated on line….), but when I change self.array1 to array1, warning goes away.
What is the reason for using self. do I need to use self if I set #property(nonatomic,retain) to variables(like array1,array2,string1,string2).
Also in dealloc method, I heard we don't want to use [self.array1 release], instead we can use [array1 release]. Is it Correct?
Do I need to release my string in dealloc method.
Also I am releasing aAppDTO in dealloc method. if I allocate some objects in anotherAppDTO class, will it release automatically when I call [aAppDTO release] method.
Can anyone clarify me.
Many Thanks,
Anish
You get the warning because when you write :
self.array1 = [[NSMutableArray alloc]init];
is the same as :
[self setArray1: [[NSMutableArray alloc]init]];
As you can notice you are not allocating the underlying array1 private variable, but you are calling the setter of the property that since it is declared as retain it retains the object once assigned, this means that when you eventually will assign another object the second time with the setter the first object will remain with a retain count of one until the application will be closed (since you don't have any reference to that object anymore ...) .
Take a look at this great article to understand better Manual Reference Counting in Objective-C .
when i analyze my app in Xcode 4.3.2, i get memory warning in self.array1 and self.array2 (Potential leak on object allocated on line….), but when i change self.array1 to array1, warning goes away.
the analyzer's right. the parameter is retained when set. as well, you should favor direct access in initialization and dealloc. so, you should just write array1 = [[NSMutableArray alloc] init];, and be done.
What is the reason for using self. do i need to use self if i set #property(nonatomic,retain) to variables(like array1,array2,string1,string2).
those go through the accessor methods. if not in initialization or dealloc, you should favor going through the accessor methods because that is the common correct execution path for a fully constructed object.
Also in dealloc method, i heard we don't want to use [self.array1 release], instead we can use [array1 release]. Is it Correct?
correct.
Do i need to release my string in dealloc method.
yes.
Also I am releasing aAppDTO in dealloc method. if i allocate some objects in anotherAppDTO class, will it release automatically when i call [aAppDTO release] method.
when its reference count reaches 0, its dealloc will be called.
I think the others have answered your question.
I do want to draw your attention to Apple's excellent Advance Memory Management Programming Guide: Practical Memory Management, in which they walk through these sorts of scenarios. It's hard to take it all in on the first reading, but it really does cover this stuff. In answer to your question about the use of instance variables versus the accessor methods, I draw your attention to the section labeled to "Don't Use Accessor Methods in Initializer Methods and dealloc".
I'm new to Obj-C and I have a question concerning the autorelease. Is it ok to return an autoreleased variable for several methods? For example:
- (void) methodC {
Object anObj = [self methodB];
//Do something with anObj
}
- (Object *) methodB {
return [self methodA];
}
- (Object *) methodA {
Object anObj = [[anObj alloc] init];
release [anObj autorelease];
}
Will the variable remain valid even if it is returned up a method chain and used at the top? Or does it have to be retained somewhere along the way?
thank you
Yes, it will be valid in this case. You only have to worry about the variable being deallocated if somebody drains the autorelease pool. As long as you've written every function that returns along the way and you don't explicitly drain the autorelease pool, you don't have to worry about objects being deallocated from under you.
In the vast majority of cases, the code in the NSRunLoop takes care of draining the autorelease pool. When you return control from your application code to the API code (such as by returning from a touchesBegan handler etc.), you don't know if the autorelease pool will be drained, so you have to assume in the worst case that it will. In that case, you have to retain any objects you want to keep references to.
For example:
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
Object *anObj = [self methodC]; // Your methodC as before -- anObj is valid
[pool drain]; // anObj will be deallocated here
The variable should remain valid. You only need to retain an object if it is actually "owned" by some other object and could be indirectly/unintentionally released along with it. For example, if you extracted an object from an array and then released the array, your object reference could become invalid unless you explicitly retain it.
For more details, see Object Ownership and Dismissal, particularly the sections on Autorelease and Validity of Shared Objects. The latter uses the following code to illustrate how you could "accidentally" make an object reference invalid.
heisenObject = [array objectAtIndex:n];
[array removeObjectAtIndex:n];
// heisenObject could now be invalid.
The following code shows how to mitigate this problem using retain.
heisenObject = [[array objectAtIndex:n] retain];
[array removeObjectAtIndex:n];
// use heisenObject.
[heisenObject release];
I have some code that looks like the following:
NSMutableArray *bar = [[NSMutableArray alloc] initWithCapacity:0];
NSMutableDictionary *foo = [[NSMutableDictionary alloc] initWithCapacity:0];
[foo setObject:[NSNull null] forKey:#"yay"];
[bar addObject:foo];
[foo release];
Instruments is showing that foo is leaking. I understand why that is happening. Foo's retain count when alloc'd is 1. Then when bar addObject's foo, the retain count goes to 2. Later when I release foo, it goes down back to 1. Still a leak. However, later on in my code, (in a separate method, which is why I think this might be shown as a leak)
[bar removeAllObjects];
Why is foo shown as leaking if I do removeAllObjects later on?
** NOTE **
I didn't include it in my original post, but bar is indeed being released in the classes dealloc method.
I think (and I think you hinted at this possibility as well) that Instruments is marking it as a potential leak, because it hasn't looked ahead far enough to see that bar will be responsible for removing/releasing all its objects in said separate method..
Given what you show, it is bar that never gets released. Calling [bar removeAllObjects] only removes the objects it contains. Instead, you should call [bar release] when you are done with bar. This will automatically release all of the objects that bar holds, plus release the bar object itself.
You state that you understand the memory management concepts, so perhaps you just didn't show bar being released in your example.
edit: I think craig has the right idea in his answer. One way to avoid the warning (maybe) would be to allocate bar in the class init method. I usually find it beneficial to maintain a symmetry between my init and dealloc methods when it comes to member variables, and this would be a good example:
- (id)init
{
if ((self = [super init]) == nil) { return nil; }
bar = [[NSMutableArray alloc] initWithCapacity:0];
return self;
}
- (void)dealloc
{
[bar release];
[super dealloc];
}
- (void)YourMethod
{
NSMutableDictionary *foo = [[NSMutableDictionary alloc] initWithCapacity:0];
[foo setObject:[NSNull null] forKey:#"yay"];
[bar addObject:foo];
[foo release];
}
The NSMutableArray should be releasing it when removeAllObjects is called. You shouldn't need to release or add it to an autorelease pool.
From O'Reilly's chapeter on Memory Management:
When you add an object to a collection, it is retained. When you remove an object from a collection, it is released. Releasing a collection object (such as an NSArray) releases all objects stored in it as well.
Perhaps something else is going on in instruments?