Coming up towards the end of developing an iPhone application and I'm wondering just how bad is it to use autorelease when developing for the iphone. I'm faced with some fairly random crashes and, so far, I can't pinpoint it to anything other than sloppy memory usage.
As a Cocoa newbie I remember initially reading a guideline document that strongly suggested avoiding autorelease in favor of manual retain/release for iPhone. However, a more 'senior' Cocoa developer came on board early on (who ironically has been let go since), who used autorelease all over the place. Admittedly, I was went into "monkey see monkey do" mode, and it appears to be coming back to haunt me (I'm now the only developer on the project).
So what to do next? It seems to me that I have to branch the code and try to go through and replace, where possible, autorelease code keeping my fingers crossed that I don't inadvertently break the app. It seems a lot of library calls result in autoreleased objects like stringWithFormat and pretty much anything where I'm not using alloc myself. Any other gotchyas and/or suggestions I should be looking out for? Thanks Cocoa gurus.
Using release instead of autorelease can improve memory usage in tight spots (which is good on the iPhone), but it's not going to help at all with crashing if you're not following the retain / release rules. I would read a few tutorials on memory management in Obj-C if you're still a little hazy on what you should be doing, and then go after those crashes using the debugger and crash reports to find out where you're over releasing objects. This and this are two good places to start.
More important than the autorelease or manual-release choice is how often you alloc and dealloc your NSAutoreleasePools. Since most of the Cocoa frameworks use autorelease liberally, you need to have a proper pool draining strategy. Once that is in place, the choice of whether to release or autorelease becomes much less an issue.
That being said, the only areas you should worry about are tight loops--allocate and release an NSAutoreleasePool every few iterations for best results; and when you have spawned another NSThread that doesn't have a Runloop--create a pool and drain it every so often becomes idle. Since most applications only allocate a small amount of data per event, UIKit's strategy of allocating the pool before the event is dispatched and releasing it after the dispatch returns works very well.
If you think you dunno how to use autorelease, check out CS193p FALL 2010 on iTunes U -> Lecture number 4.
It teaches you all about memory management and stuff (if you skip the first 10 minutes or so)
For iPhone performance reasons, Apple suggest that, whenever possible, you shouldn't use autoreleased objects. Instead, explicitly release your objects when you are done with them.
Using autorelease pools means that you might be leaving some unused memory lying around. Since the iPhone has less memory to go around, you might improve performance if you free up unneeded memory as soon as possible, rather than letting it sit around taking up resources while it waits for an autorelease.
When you autorelease, you're basically saying: "I don't need this any longer, but anyone else is free to pick it up (before the auto release pool is drained)". When you explicitly relase an object you're saying: "I don't need this any longer and unless anyone else has already said otherwise (acquired), it should be deallocated immediately."
Consequently, autorelease is not normally the wrong thing to. It is required when you want to pass objects back to the sender of a message without requiring the sender to take care of releasing the object.
Related
It's a weird situation for me that I cannot run my project on device or emulator but when I choose profile instead of run option, the app run flawlessly without any zombie guys.
It happens after I convert my project to ARC. I just modify code as Xcode tell me todo and due to the size of this project, I cannot look through every line of code.
ps. I'm the third hand on this application, so it's almost impossible for me to understand 10k lines of code.
Have you tried enabling Zombies in Xcode itself without profiling? This will set objects to never dealloc so that when you message an object that has a zero retain count, it will know what the object is and tell you. Just make sure you turn it on again so that objects will dealloc as normal.
See how to do that here:
How to enable NSZombie in Xcode?
the following can help you after the fact, but it's best IMO to perform them before migration; if a problem exists, ARC will solve some issues while abstracting others from you:
1) Create more Autorelease Pools one approach which might help you narrow things down is to explicitly create autorelease pools -- this can help localize some of your app's memory related issues. explicitly adding autorelease pools has other benefits, so this can be done not only for bug-seeking.
2) Use GuardMalloc as well, there are other memory related tools -- your app should also run fine with GuardMalloc enabled. switching to ARC could change the point of destruction -- you may be holding on to a dangling pointer.
3) Remove all Leaks finally, this may sound backwards -- remove all leaks possible. you want memory operations and lifetimes well defined. if you have an occasional leak, your issue could be hard to detect. oftentimes, reducing leaks can help you isolate the problem by making the problem easier to reproduce.
I have been using instruments to check for leaks and other memory issues in my program. Though the leaks found by instruments are extremely small and don't matter, I have found that the physical memory free keeps going down while I use the program.
I use memory monitor to determine how much memory my app is using up and allocations to determine where this is mainly happening. I always make sure to release every time I alloc or retain, and seeing how there are barely any leaks, I'm assuming that my memory management is fine.
Does anyone know what I can do to fix this issue or reccomend a way to get to the bottom of it?
Even tho you release objects you dont need, that doesn't matter. You are probably allocating too much things and keeping them for some reason. You can try to check this out:
http://macdevelopertips.com/objective-c/objective-c-memory-management.html
http://akosma.com/2009/01/28/10-iphone-memory-management-tips/
I would advise you to check what you alloc and what you keep for the life of the application and see if you can make the same thing but without using so much memory.
Edit: I have to agree with Mark and Kongress, every leak matters for the sake of your app's life.
I have a navigation based template, when I run my application using Instruments, the very first memory leak comes under:
Leak Object: Malloc 128 bytes
Responsible Library: CoreGraphics
Responsible Frame: open_handle_to_dylib_path
I don't know where this leak is coming from and how remove this.
If it's a default leak, then I think I don't need to worry about it. But if it's not then I have to find a way to remove the leak.
Expanding on deanWombourne perfectly correct answer a bit..
The Leaks Instrument shows you memory that isn't going to be free'd in the normal course of the app (because there aren't any references to it). This in itself is no biggie, it will be free'd when the app exits. A lot of the framework code will allocate and leave these very small chunks of memory allocated. I have no idea if they are mistakes or essential to how the app runs. Whatever, we must accept that they are completely normal.
Leaks will identify these chunks of memory as 'Leaks' and that sounds bad, but this is not really the 'Leaks' that the instrument is there to help you identify.
The 'real' leaks are in the code that can be run many times and which allocate some memory that is never freed, so over time will consume more and more memory until all memory is used and your app will crash.
So if you have an app that no matter how long you use it for or no matter how you use it, it 'leaks' 128 bytes in an apple framework you generally don't have to worry.
However, if you have an app that say, every time you click a button it allocates a new string which is never released - no matter how many bytes the string is - if the user pressed the button enough times this would consume all the memory available to app and eventually crash it. This is the kind of leak you need to watch out for.
The leaks instrument realistically can't tell the difference between the two kinds, but you need to be able to. You might want a kind of singleton object, for example, that there is only ever one instance of, and that needs to exist for the entire lifetime of your app. You create the object on app startup and realistically you never need to free this object, it can be killed when the app exits. Leaks will flag it as a leak, and some other developers that you work with who assume that this means you don't know what you are doing will run to your boss like a little child and say "He's writing really leaky code, and that's reeeeally bad". And your boss, who isn't a programmer will take him seriously because it does sound bad and anyway he scraped a 2.2 in CS from a reputable University so he must know what he's talking about. When really it is completely reasonable and exactly what you meant to do.
So, use the Leaks instrument to find bugs in your code that will ruin your app. Don't worry about every byte found 'Leaking' in an Apple framework.
If it's a one off 128 byte leak then don't worry about it at all, there are better ways to spend your time than thinking about this :)
I have a C++ class that I'm using from my Objective-C++ controller in my iPhone app. The C++ class does some calculations on some data, returns a result, and then is done -- but it leaks like crazy. I'm wondering if I can somehow make use of Memory Zones (aka malloc zones aka allocWithZone) to solve this. My idea is to allocate the ObjC++ object in a new zone, and then somehow have the C++ objects all be automatically created in this new zone. Then, when it returns, I kill the zone, and all of the memory will automatically be recovered, even if it has been leaked.
However: the documentation seems to indicate if I allocation an object in a new zone X, objects that it allocs will not automatically also be in zone X. If that makes sense, does anyone know how to override that behaviour so that all subsequent allocs and mallocs by that object will be in the new zone X?
EDIT:
I should note that the thread will be running mainly C++ code, a large code base, and it's not economical at this point to kill all of the leaks in it since it was automatically converted from Java and leaks like crazy all over the place (refactoring required...). Thanks for the "just fix your leaks" advice but that's not practical at the moment.
The memory is not being leaked through ObjC allocations, but mainly through C++ array new calls (a couple of direct mallocs as well). If that makes a difference.
Originally, zones in Objective-C were designed to enable the developer to allocate a bunch of related objects in a zone and then release them all without individually deallocating each instance.
In practice, this proved to impractical. Especially once the move from Object to NSObject was made (from NeXTSTEP to OpenStep).
The reality is that object graphs within applications are generally complex enough that total zone isolation of a sub graph is nigh impossible. In particular, you can't allocate, directly or indirectly, any objects from Apple's frameworks and hold references to them because you have no way of controlling the zone based allocations of said objects.
So, no, don't do that. Fix your leaks. There is no magic bullet / mechanism to avoid having to make your code actually work.
Just fix your memory leaks...
Isn't the idea to code so that there aren't any leaks? Not bothering to clean up memory leaks is a bad way to go about business!
What you're discussing was part of the original thought with zones, but that aspect hasn't worked out so well.
The way to avoid leaking is just to avoid leaking. Free what you malloc, -release the objects you need to release.
It's really not that hard to keep from leaking. It happens, but you find the leak and fix it. To create another system, possibly complicated, to avoid a small bit of forethought and discipline, is not worth the effort.
I'm looking for a primary source (or a really good explanation) to back up the claim that the use of autorelease is dangerous or overly expensive when writing software for the iPhone.
Several developers make this claim, and I have even heard that Apple does not recommend it, but I have not been able to turn up any concrete sources to back it up.
SO references:
autorelease-iphone
Why does this create a memory leak (iPhone)?
Note: I can see, from a conceptual point of view, that autorelease is slightly more expensive than a simple call to release, but I don't think that small penalty is enough to make Apple recommend against it.
What's the real story?
(cannot accept your own answer?)
Well, after all that, I did manage to find a reference from Apple Developer, added as a side-note near the bottom of the page:
iPhone OS Note: Because on iPhone OS
an application executes in a more
memory-constrained environment, the
use of autorelease pools is
discouraged in methods or blocks of
code (for example, loops) where an
application creates many objects.
Instead, you should explicitly release
objects whenever possible.
Still, this suggests using autorelease carefully, not avoiding it altogether.
(and now for my comment)
It sounds like there is a certain amount of overhead in maintaining the pool. I read this article which would lead me to probably avoid autorelease as much as possible because I prefer things to be consistent. If you have some memory under autorelease and other memory being totally manually managed it can be a bit more confusing.
It is not the question to use or not to use autorelease, because in some cases autorelease is the only way you'll get through. The question should be "Why not to use autorelease on all objects, instead of using retain and release?".
To answer that, you should first learn what's a proper use for autorelease. Let's say that you have a class that has two properties: firstName and lastName. There is a getter and a setter for each. But you also need a method that would return fullName, by concatenating these two strings into a brand new string:
- (NSString *) fullName {
NSString str = [[NSString alloc]initWithFormat:#"%# %#", firstName, lastName];
// this is not good until we put [str autorelease];
return str;
}
What's wrong with that picture? The reference count on the returned string is 1, so if you don't want to leak, the caller should release it when he's done. From the caller's point of view, he just requested a property value fullName. He is unaware of the fact that he got a brand new object that he should release after usage, and not some reference to an NSString internally held by the class!
If we put the [str release] before return, the string would be destroyed and the method would return garbage! That's where we use [str autorelease], to mark the object for release at a later time (typically when the event processing is done). That way the caller gets his object, and does not have to worry whether he should release it or not.
The convention is to call autorelease on a new object before the method returns it to the caller. Exceptions are methods with names that start with alloc, new or copy. In such cases the callers know that a brand new object is created for them and it is their duty to call release on that object.
Replacing release with autorelease altogether is a bad idea, since the objects would pile up and clog the memory very quickly, especially in loops. The resources on the iPhone are limited, so in order to minimize memory hogging, it is your duty to release the object as soon as you're done with it.
I disagree that avoiding autorelease altogether is wise.
Cocoa Touch uses it quite frequently internally and for many situations it's the only way to allocate memory properly (a good example is reusable table view cells). If you understand what is happening, the autorelease pool is a great tool at your disposal. The main thing to remember is that the blocks are not freed until some point later in the run loop. If you are running a tight loop without user interaction and are piling up autorelease blocks, you will eventually run out of memory.
Autorelease is not a substitute for garbage collection (not available on in the iPhone SDK) and can lead to nasty dangling pointer bugs (the pointer still seems to be good, then at some unpredictable point goes invalid), but is also very useful in writing clear and easy to maintain code. Consider the following case:
[aDictionary writeToFile:
[documentsDirectory stringByAppendingPathComponent:#"settings.plist"]
atomically:YES];
The path string is generated as an autorelease object. We aren't required to create a temporary object, so we avoid that overhead (and the possibility we might forget to release it). The memory will be fully released (no leaks), just that it will happen later in the run loop. Ask yourself: am I going to allocate hundreds of these before I get back to user input? If no (as would be the case here), autorelease is a great solution and indeed this NSString method for working with paths is only available using autoreleased memory.
I do agree with the above poster that following convention and being consistent is a very good idea.
I tend to avoid using autorelease on the iPhone where I can (as Jon points out, you can't always do without it), simply because I like to know that the objects I'm working with are released the instant I don't need them. Memory constraints are one of the largest problems you'll face on the device and I believe they're the source of most of the crashing issues you'll find out there.
As highlighted by Apple, a particular area of concern is when you use autoreleased objects within any kind of loop, because they'll pile up within the autorelease pool. You then have to manage when to drain the pool or create / release one. Doing that every pass through the loop might degrade performance, but going too many passes without could lead to dangerous memory usage. I'm still tweaking this in Molecules, because there are intermittent memory issues when importing large (>2 MB) text files from the Protein Data Bank. I was able to improve performance by minimizing autoreleased objects, but couldn't eliminate them completely.
Another area to watch out for is using autoreleased objects with threads. If at all possible, do not use autoreleased objects when dealing with methods performed on a background thread, because the pool can be drained at random times. This leads to intermittent crashes that can be really fun to track down.
I would highly suggest avoiding autorelease like the plague. Memory management bugs are a great way to waste massive amounts of time and money, I've had the dubious honor of going through the process many a time on old Mac apps, and the fact that the iPhone has tight memory constraints mean that you have to be extremely careful, or the app will just be unstable and crash often...like so many of the first apps that were released last summer.
The only reliable way I've found to write stable iPhone applications is to manage all your memory yourself, and do it consistently. Even if you are the only programmer on your project, you'll thank yourself later. It can be difficult if you learned to program in languages that "take care of everything for you," but it really is worth learning how to do well if you are serious about createing quality iPhone apps.