Non-ARC Project: NSMutableArray, NSString Memory Leak - memory-leaks

Question

Our company team works on an existing application. That project is non-ARC (automatic reference counting). There is doubt occurs about release the object following code.
Code 1: Why is there no crash when I execute this code?
NSMutableArray *arraytest=[[NSMutableArray alloc]init];
for(int i=0;i<100;i++)
{
NSString *str=[NSString stringWithFormat:#"string:%d",i];
[arraytest addObject:str];
}
NSLog(#"arraytest before:%#",arraytest);
[arraytest release];
NSLog(#"arraytest after:%#",arraytest);
Similar code: with mutable copy
Code 2: After the changes the following code crashes at the last line.
NSMutableArray *arraytest=[[NSMutableArray alloc]init];
for(int i=0;i<100;i++)
{
NSString *str=[NSString stringWithFormat:#"string:%d",i];
[arraytest addObject:str];
}
NSLog(#"arraytest before:%#",arraytest);
NSMutableArray *copyarray=[arraytest mutableCopy];
[arraytest release];
NSLog(#"copyarray:%#",copyarray);
NSLog(#"arraytest after:%#",arraytest);
Why is there a memory leak in this line?
And why is there a memory leak in this line?
What is the correct method to execute the above code without memory leaks? Our company guys tells autorelease should not be used above code.

Answer 1

Consider your first example:
NSMutableArray *arraytest = [[NSMutableArray alloc] init];
// `arraytest` populated ...
NSLog(#"arraytest before:%#", arraytest);
[arraytest release];
NSLog(#"arraytest after:%#", arraytest); // DANGER: referencing dangling pointer!!!
That last NSLog statement is exceedingly dangerous, because after having called [arraytest release] (reducing the array's retain count from +1 to 0), the object pointed to by arraytest will have been deallocated and arraytest is now a dangling pointer to that deallocated memory. You should never reference a pointer after it's been deallocated. Sometimes it may look like you can use it, but it's not safe, and your app can now unexpectedly crash. (If you used zombies, though, it would have safely warned you of your attempt to incorrectly use this dangling pointer.)
Consider your second example:
NSMutableArray *arraytest = [[NSMutableArray alloc] init];
// `arraytest` populated ...
NSLog(#"arraytest before:%#",arraytest);
NSMutableArray *copyarray = [arraytest mutableCopy];
[arraytest release];
NSLog(#"copyarray:%#", copyarray);
NSLog(#"arraytest after:%#", arraytest); // DANGER: referencing dangling pointer!!!
In this example, you still have that very dangerous NSLog of arraytest at the end, after you've released it, and your use of that dangling pointer could easily crash. So you'd want to get rid of that.
But you now have introduced a leak. While you've released the object that arraytest originally pointed to, you have not released the object that copyarray points to, the result of the mutableCopy. Thus, this new copyarray instance will leak. And thus, all those strings that were originally allocated when you created arraytest will now be referenced by the leaked copyarray and they'll leak, too.
If you added a [copyarray release] to the end of this routine, both the leaking array and the leaking strings would have been resolved.
Now, consider your third example, shown only in the final Instruments screen snapshot:
NSMutableArray *arraytest = [[NSMutableArray alloc] init];
for (int i=0; i<100; i++) {
NSString *str = [NSString stringWithFormat:#"string:%d", i];
[arraytest addObject:str];
[str release]; // DANGER: released `str` whose ownership was never transferred to you!!!
}
NSLog(#"arraytest before:%#",arraytest);
NSMutableArray *copyarray=[arraytest mutableCopy];
[arraytest release];
NSLog(#"copyarray:%#",copyarray);
NSLog(#"arraytest after:%#",arraytest); // DANGER: referencing dangling pointer!!!
In this final example, we are compounding the problem, by overreleasing the string that you just added to the array. So you created an autorelease object (effectively the retain count will be zero when the autorelease pool is drained), added it to the array (increasing its effective retain count to +1), and released the str (reducing it's retain count back to +0 upon draining of the pool).
The app is now in an unstable situation, because the array is now referencing objects that could be released when the autorelease pool is drained, ending up with an array of dangling pointers. Worse, if this array were ever properly released itself, all of those strings would be overreleased.
And, of course, you still have the leaking of the array, as discussed in the second example, above. But if you did properly release this copyarray, all of those strings would be overreleased.
Probably needless to say at this point, but the way to eliminate this leak is to simply release the copyarray:
NSMutableArray *arraytest = [[NSMutableArray alloc] init];
for (int i=0; i<100; i++) {
NSString *str = [NSString stringWithFormat:#"string:%d", i];
[arraytest addObject:str];
}
NSLog(#"arraytest before:%#", arraytest);
NSMutableArray *copyarray = [arraytest mutableCopy];
[arraytest release];
NSLog(#"copyarray:%#", copyarray);
[copyarray release];
This follows the Basic Memory Management Rules, namely that you are responsible for calling release on those objects that you own by virtue of having received them from a method starting with alloc, new, copy, or mutableCopy).
A couple of closing observations:
If you're going to use manual reference counting, I'd suggest that you make frequent use of Xcode's static analyzer (shift+command+B, or "Analyze" on Xcode's "Product" menu). It's surprising good at identifying manual reference counting memory problems. Instruments is useful, but as shown by our third example above, you can easily be drawn to incorrect conclusions (e.g. "gee, I need to release all those strings"). The static analyzer would have pointed out some of these problems for you.
Bottom line, always make sure you have a clean bill of health from the static analyzer before proceeding further. There is no point in trying to reverse engineer what problems may be manifested in Instruments when the analyzer could have told you precisely what the issue was.
I would advise not drawing any conclusions from the fact that a particular dangling pointer didn't crash your app, but another did. It's just not predictable. If you turn on zombies (only temporarily, for development/testing purposes, not for production apps), that will bring your attention to any attempts to reference a previously deallocated object.
I notice that you're using NSString in your tests. You should be aware that NSString has internal memory optimizations that can yield non-standard behavior. I'd be wary of using NSString in these sorts of experiments.
Don't get me wrong: If you follow all of the Basic Memory Management Rules, NSString will behave properly. But if you're trying to examine what sort of errors/crashes result when deliberately not following those memory management rules, be aware that NSString can be misleading.
Needless to say, using ARC will greatly simplify your life. See the Transitioning to ARC Release Notes for more information.