I am not clear about how to use autorelease;
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
RetainTracker* tracker = [RetainTracker new];
[tracker retain];
[tracker retain];
[tracker autorelease];
[pool release];
Is there any memory leak in the above code?
I know the autorelease just puts tracker into NSAutoreleasePool, without modifying the reference count for tracker. When i call [pool release], the object receives one message release, then the reference count of tracker is 2. So the compiler can't call the dealloc function of object tracker, so there is a memory leak.
So i get this: we shoul call retain and release same times, is it right?
If you're new to Objective-c, you should be using Automatic Reference Counting. Almost everyone should. But for the sake of understanding:
An object has a reference count of how many objects have a reference to it. When it drops to zero, the object is not referenced by anything and is deallocated. Every method in Objective-C is responsible for releasing any object it retains. The problem is, if a factory method's job is to create an object, it's breaking the rules by not releasing an object it retained (in this example it was retained because it was created). If the method called release on the object right before returning it, it would be returning the address to an object that is already gone. So, there is autorelease, which temporarily delays the release until the calling method can retain the object the called method created.
In your example above, if you got rid of the 2 retains, and only called autorelease, then the object would get released and deallocated when the autorelease pool is released and (right before deallocation) is drained, meaning it calls release on all objects in its pool, tracker being one of them because calling autorelease on tracker added it to the pool.
new is equivalent to doing an "alloc" & "init", so retain count on tracker on that line is 1.
Then you increment the retain count 2 more times to give a total retain count of 3.
Autorelease sets the tracker to be released when the pool is released (and the retain count is decremented as well). But it's already retained 3 times, so it doesn't really get released.
And yeah, there is a memory leak with the retain count being greater than 0 and no reference to "tracker" outside of that method (that is, unless you're using "tracker" in an instance variable).
It's very good to know the basics of memory management; but if you want to save yourself a ton of headache, just do what everyone else here seems to be saying and simply enable ARC.
EDIT: And to finish your question, you should make sure every call to retain is balanced with a release. You also do a "new", which also increments the retain count so you need to "release" because of that as well.
Related
I'm still not 100% with ARC internals.
A few examples that I would like clarified:
What happens with someObjectToReturn = [[SomeClass alloc] init]; that is allocated inside a method and returned? If someObjectToReturnis assigned to e.g. someObject, when will someObjectToReturn be released? When someObject is nilled or does someObjectToReturn still need to be added to an autorelease pool?
Another case is if an array of objects is nilled, are all the objects released?
Lastly, where is a good place to release a copied block object? Or will the block still be released after execution? If the copied block is added to an autorelease pool, when would one drain that pool?
Lets say there are 10 blocks, each added to an autorelease pool, draining it too soon would result in the executing blocks to die. Can a copied block be nilled from within itself, such as dispatching the nilling of the block back to the main thread?
You seem to be overcomplicating things. Under ARC, you can't release objects, or drain autorelease pools, so there is no "right" time to do this. Don't think about retain and release and autorelease (except in tight loops), think about object ownership.
Your specific questions:
The object will be released when the variable that the return value is assigned to goes out of scope or is set to nil. You don't have to worry about it.
Yes, all the contents of an array are released when the array is set to nil, you don't have to worry about it
You can set the value holding the copied block to nil when you're done, or it will disappear when the object owning the copied block goes. You can't drain an autorelease pool under ARC, you can wrap statements in an #autoreleasepool{} block, but this just captures everything in the block - you don't "add" things to the pool or "drain" the pool.
I am trying to know about release keyword. I allocated it once, and then I released it. then also the message was passed to that object. And it gives me output. But the retain count is zero. What is the reason behind this?
MyClass *obj=[[MyClass alloc]init];
[obj release];
[obj WhoAreYou];
I given "NSLOG(#"It is the problem.");"
I got the out put: It is the problem.
See this link..a simple tutorial on memory management..It says
You can think of release as saying
relinquish ownership of this object,
rather than destroy this object
That means when you release you are just losing your control over the object..You are not releasing it..Cocoa will release the variable if it is not referenced by anyone else
I've read apple documentation to assert that I was doing the memory management correctly but some questions raised.
Question 1:
They exhibit this code snippet as wrong :
in obj implementation:
- (NSString *)method1 {
NSString *string = [[NSString alloc] initWithFormat:#"%# %#", firstName, lastName];
return string;
}
... later ...
NString* myString = [obj method1];
NSLog("%#", myString);
[myString release];
Apple Doc :
You own the string returned by alloc, but lose the reference to it before you get a chance to relinquish ownership. Following the memory management rules, this would result in a memory leak, since the caller has no indication that they own the returned object.
Since I'm taking care of releasing the object that has been allocated previously, there is no memory leak, right ? What do they mean by "lose the reference to it" ?
It is wrong only regarding apple's memory management recommendations (the caller has no indication that they own the returned object) or this is also technically wrong ?
Question 2 :
This is about autoreleased objects availability :
Example code:
in obj1 implementation:
- (NSString *)methodA {
NSString *string = [[NSString alloc] initWithFormat:#"%# %#", firstName, lastName];
return [string autorelease];
}
in obj2 implementation:
- (NSString *)methodB:(NSString *)inputString {
NSLog("%#",inputString)
//*other call of methods with arg inputString*//
}
... later ...
NString* myString = [obj1 methodA];
[obj2 method2:myString];
How far (or deep) following my functions calls will the autorelease object returned by obj1 will be available. Regarding apple's documentations "Autorelease objects will be available within their variable scope". Should I retain it at some point ?
Q1: It is wrong only regarding apple's memory management recommendations (the caller has no indication that they own the returned object) or this is also technically wrong ?
Technically this is correct as you release myString after using it. However if you follow Apples guidelines for method naming (strongly recommended), this is clearly wrong:
You own any object you create.
You “create” an object using a method whose name begins with “alloc” or “new” or contains “copy” (for example, alloc, newObject, or mutableCopy).
method1 doesn't contain create, alloc, new or copy - thus per the guideline the caller doesn't own the object and doesn't have to release it.
Q2: How far (or deep) following my functions calls will the autorelease object returned by obj1 will be available. Regarding apple's documentations "Autorelease objects will be available within their variable scope". Should I retain it at some point ?
Auto-released objects will be alive until the closest Autorelease Pool is drained, see Autorelease Pools:
An autorelease pool is an instance of NSAutoreleasePool that “contains” other objects that have received an autorelease message; when the autorelease pool is deallocated it sends a release message to each of those objects. An object can be put into an autorelease pool several times, and receives a release message for each time it was put into the pool. Thus, sending autorelease instead of release to an object extends the lifetime of that object at least until the pool itself is released (the object may survive longer if it is retained in the interim).
...
The Application Kit automatically creates a pool at the beginning of an event cycle (or event-loop iteration), such as a mouse down event, and releases it at the end, so your code normally does not have to worry about them. There are three cases, though, where you might use your own autorelease pools:
...
So, if you need your instances to stay alive after the corresponding autorelease pool was drained, take ownership by retaining them. Otherwise you usually just let them be handled by the pool.
Since I'm taking care of releasing the object that has been allocated previously, there is no memory leak, right ?
right
What do they mean by "lose the reference to it" ?
you hold no pointers for the object, such that the object may not be accessed in your program.
It is wrong only regarding apple's memory management recommendations (the caller has no indication that they own the returned object) or this is also technically wrong ?
also correct. the static analyzer will prolly cry too
How far (or deep) following my functions calls will the autorelease object returned by obj1 will be available. Regarding apple's documentations "Autorelease objects will be available within their variable scope". Should I retain it at some point ?
this is a little more complex. autorelease pools are stacked upon each other by thread. that's why you must create one when entering a thread or new event loop iteration, and also why it is a good idea to create them explicitly when performing large operations which create many (autoreleased) allocations.
finally the last pool in the stack (for the thread) is destroyed at the end of the run loop's iteration.
if the object is created under an autorelease pool you create explicitly, then you must retain it to use it beyond the lifetime of the pool which it was created in.
similarly, you must formally retain/copy when passing to other threads. typically, this happens immediately - you just create a copy or retain the formal arguments when entering the implementation of the secondary thread.
I want to ask about the iPhone application and objective C question. In the implementation program, there are function called 'dealloc', does this function only be called one time by the application?
For example, if I alloc a object and retain it 2 times, the retains count is 2 and I never use 'release' in the program, unless in the dealloc. Will the object be removed from the memory, or the objective will be removed from the memory. Thank you.
In the implementation program, there are function called 'dealloc', does this function only be called one time by the application?
Yes. -dealloc destroys the object. Trying to send any message to it again, including -dealloc is an error.
if I alloc a object and retain it 2 times, the retains count is 2
Careful. The retain count is at least 3. Other things than your code might retain the object. It's better not to worry to much about retain counts and only think in terms of ownership.
Each alloc, new, copy or retain is an claim of ownership. The object's dealloc method will only be called when all claims of ownership have been relinquished. A claim of ownership is relinquished by sending -release. So if you never release an object except in its own dealloc, you'll never release it.
dealloc is called once by the system when the object is destroyed (when its reference count reaches 0). If you have member variables in your class that you alloc in your init function, you must release them in your dealloc function.
If you give someone a pointer to one of those member objects and they retain it, the member could survive the release in your dealloc, but by sending a retain message they are taking responsibility for sending a release message later, ensuring its eventual destruction.
I still have some unclear understand about release and autorelease. What are the difference between both of them? I have this code. For facebook connection. I crash it sometimes when I go to Facebook login, I doubting maybe it is because I don't release the object nicely.? Thanks for any helps
if (_session.isConnected) {
[_session logout];
} else {
FBLoginDialog* dialog = [[[FBLoginDialog alloc] initWithSession:_session] autorelease];
[dialog show];
}
The Memory Management Programming Guide for Cocoa will soon be your best friend. In brief, object instances in Cocoa are memory managed using reference counting (unless, of course you're using garbage collection on OS X). An object indicates that it wants to 'retain' an ownership interest in an other instance--keep it from being deallocated--by sending it a -retain message. An object indicates that it wants to release that interest by sending the other instance a -release message. If the number of objects that have 'retained' and ownership interest in an object drops to 0 (i.e. when the last of the owning instances sends a -release message), the instance with a 0 retain count is deallocated.
It's sometimes convenient to say "I want this instance to be released some time in the future". That's the purpose of -autorelease. Sending an -autorelease message adds the receiver to the current NSAutoreleasePool. When that pool is drained, it sends a -release message to all the instances in the pool. An NSAutoreleasePool is automatically created at the start of each iteration of each thread's run loop and drained at the end of that iteration. Thus, you can do something like this in a method:
- (id)myMethod {
return [[[MyObject alloc] init] autorelease];
}
The caller of this method will get back an instance that they can -retain if they wish to keep it. If they don't retain it, it will stick around at least until the enclosing autorelease pool is drained:
- (void)someOtherMethod {
...
id instance = [obj myMethod];
... // do more with instance, knowing that it won't be dealloc'd until after someOtherMethod returns
}
Releasing means you release that right away.
Autoreleasing means you want the variable to be released on the next autorelease pool.
You use autorelease when you want to keep retaining the variable but don't want to create a memory leak. You use release when you don't need the variable anymore.
Sample:
- (NSNumber *)return5 {
NSNumber * result = [[NSNumber alloc]initWitnInt: 5];
[result autorelease];
return result;
}
Why do we use autorelease there?
If we use [result release] instead, variable result will be destroyed AT that time. Which means that the returned value will be garbage.
If we do not release at all, variable result will be hold FOREVER incurring memory leak.
We can tell every caller to the function to release result but that would be a headache and prone to error.
So we use autorelease. We mark the variable to be released on the next autorelease pool. Basically we mark the variable to be released near the alloc. Hence the mantra alloc is paired with release in the same function holds all the time.
Actually, you'll do fine changing all release into autorelease. Your memory use won't be efficient, however, the effect is minimal. All variables, in all programming language is effectively autoreleased.
Anyway, use ARC.
background discussion:
objective-c is reference counted, so objects are deleted when the reference count reaches 0. release reduces the reference-count immediately, autorelease reduces it when the autorelease-pool is popped
when to use:
use autorelease when allocating the object if
you do not need it after the current function
it will be retiained by some other objet/function and will be released by a later by the retaining code
when the logic of the current function is tricky, so you would have to send release in a dozen different places before doing a return
use "manual" release
to revert a previous retain (in case you are implementing a library)
if you need precise control of freeing objects (e.g. they use lots of memory or the autorelease pool will not be popped for some time)
but really my freand:
read the Memory Management Programming Guide for Cocoa as suggested by Barry and run your code with instruments (zombies and leaks) often to catch any and almost all memory management errors.
Erik
According to the Memory Management Programming Guide for Cocoa:
The autorelease method, defined by
NSObject, marks the receiver for later
release. By autoreleasing an
object—that is, by sending it an
autorelease message—you declare that
you don't want to own the object
beyond the scope in which you sent
autorelease.
Also:
The autorelease method thus allows
every object to use other objects
without worrying about disposing of
them.