I converted my project to using ARC and i works fine in iOS 5. But when running on the 4.3 simulator, i get a lot of these messages:
2011-10-16 12:23:29.915 iRoster[1604:1300b] * __NSAutoreleaseNoPool(): Object 0x5176e60 of class EKCalendar autoreleased with no pool in place - just leaking
I guess I could put a lot of #autoreleasepool around, but I had the impression that was optional. And the strange thing is that it only appears when running on 4.3
What should I do?
EDIT:
I have now placed some #autoreleasepool around and that reduced the messages a lot, so that seems to be the case.
If you have your own autorelease pools within your application logic that you manage yourself pre-ARC, you need to replace them with #autoreleasepool constructs, and the compiler will deal with them accordingly.
Converting to ARC doesn't necessarily mean your existing autorelease pools are no longer needed — you'll still need individual pools to contain temporary autoreleased objects in, for example, loops in other threads, so they won't spend forever in memory and/or start leaking in those threads. See this Apple documentation on using autorelease pools.
Related
I am new to iOS 5 and ARC, so pardon my silly question.
If we use ARC in our project, does it mean that there wont be any memory leaks at all.
Is there a need to use Instruments for detecting memory leaks and NSZombies if we use ARC?
ARC will help you eliminate certain types of leaks, because you won't forget to release or autorelease single objects. For example, this type of error becomes impossible:
myLabel.text = [[NSString alloc] initWithFormat:#"%d", 17];
// oops, just leaked that NSString!
However, ARC will not eliminate leaks caused by retain cycles. It's still up to you to eliminate retain cycles, either by using weak references or by manually breaking the cycles before they become leaked. For example, as we start to use blocks more, block/self retain cycles become much more common. The Transitioning to ARC Release Notes discuss how to avoid these cycles using weak references.
No, that does not prevent memory leaks from happening. What happens in runtimes with reference counting, is that sometimes your code leaves dangling references, and then objects are not freed. It's still up to you to write good code.
If we use ARC in our project, does it mean that there wont be any memory leaks at all.
There may still be leaks -- In your program, and in the libraries you use. As well, ARC only applies to ObjC objects - you can easily leak any heap allocation which is not an objc object (e.g. malloc/new).
Is there a need to use Instruments for detecting memory leaks and NSZombies if we use ARC?
Yes. The previous response should detail why your program is not guaranteed to be free of these problems. Also, the compiler can get it wrong if you do silly things, and you can certainly cause problems if don't protect your data properly (e.g. concurrent execution).
I found that (for example) a UI object, like UIPickerView, is allocated and release frequently, even the corresponding dealloc method is called (proved by using Instruments), the Heap still grows up.
Is there a way to trigger the optimization of the autorelease pool to improve the whole scenario ?
My application needs to take photo, manage photo and upload to server. Over period of time, the Heap grows large and finally it crashes my application. ** I checked that there is no obvious memory leakage * with the use of Instruments.
Any Help or suggestion ?
Thanks.
You can create your own autorelease pool at places which make sense to your application. The following way of creating autorelease pools works with or without ARC.
// Stuff you plan to keep around after finishing the block below
#autoreleasepool {
// Load an image, send to server
}
// The images are released
It sounds like it is taking some time for your memory to get out of hand. If you are doing your work in the main UI run loop you should have autorelease occurring very regularly, so I'm not sure that another autorelease pool will help you. Perhaps you are keeping your references in such a way that they are not being released because they could still be used. Many leaks occur because objects are not removed from arrays, sets, and dictionaries.
I am writing an iPhone app that starts taking up memory as soon as it starts and just keeps taking up more memory. The reason appears to be that I've included a tight inner loop in that I'd like to run for a long while. Dont' worry, it's not supposed to be part of the user interactive app, it's just for testing the internal code.
In any case, by searching stackoverflow I found out that I should use my own NSAutoReleasePool because the main one is not getting reached. Also, I found that I should eschew use of autorelease. I've done both of these things, although I haven't been able to get rid of all autorelease calls. These do not fix the problem, however. Now my number of allocations (as per the instruments Allocations tool) travels in a triangle wave pattern, presumably because of the pool draining, but the number of allocations and the overall bytes creeps ever upwards. This increase in memory usage is also reflected in activity monitor. The objects that are getting allocated fall under all sorts of types including Malloc, CFString, NSConcreteMutableData; basically many core library classes and many of my code's objects.
This is basically what I'm doing:
for (int i=0; i<1000; i++) {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
... do lots of stuff
[pool drain];
}
Any ideas why this is happening? I don't have any memory leaks according to the Leaks instrument and I don't have NSZombieEnabled set or any other arguments for that matter.
Thanks
UPDATE:
I just noticed some memory leaks are getting found when I use the auto release pool that aren't there when I'm not use the pool. Strange... Maybe that helps point towards the problem. I'm trying to track those leaks down now but so far they don't look like leaks in my code, but they make sense if the pool isn't actually releasing them.
UPDATE:
Ok, figured it out and it was caused by a few things. First, I was not properly releasing objects that contained references to each other so these never ended up getting released. Second, there are still memory leaks but these are in the foundation classes. I found an answer somewhere suggesting that this was not surprising, especially when running in the Simulator so I'm not going to worry about it too much. Hopefully this is useful to someone.
This can be caused by certain system caching, i.e. ImageNamed and certain URL calls will actually be cached by the system and are therefore not leaks but also nothing that you can release manually. There are normally better ways to handle such things for example creating your own image caching which you can clear...
Above given images is of my application leaks.
Here I want to understand that, in Extended Detail - you can see different colors like light green, light pink, light brown, light purple.
What does each color indicates?
Now the other confusion is "How to locate the code which is creating a memory leak?"
Upto what limit of memory leak - the actual iPhone can go on with.
(suppose 10 bytes no problem, 20 bytes no problem & 200 bytes a problem)
What does each color indicates?
Which color indicates our code / From which detail we can get to the code where we have allocated the object & forgot to dealloc it?
(For example - On clicking of UIKit second cell in detail - we cant get to the code)
Why we must resolve all the leaks? - even a single leak can chock up iPhone ?
Why iPhone allows leaks to be remain in memory? / why garbage collection isn't done automatically after termination of application?
If I try to dealloc objects which should be deallocated according to instruments, My application terminates abnormally. If I don't dealloc, My application runs perfectly, How?
Why it is suggested that you wait in a view up to 10 or more seconds, if there is a leak, leak will be detected by Instruments?
Ignore the colors, in that one the [DashBoard viewDidLoad] is the source of the leak, something in how it's initializing a URLConnection (possibly you did not free that when the connection was finished?)
Now to answer the other questions you had:
Why we must resolve all the leaks? -
even a single leak can chock up
iPhone ?
Yes. Part of the reason is not only that you will simply run out of memory, but since there is only so much memory to go around for the whole phone a watchdog application is constantly monitoring your app and will shut it down early if it sees memory use only ever growing...
Why iPhone allows leaks to be remain
in memory? / why garbage collection
isn't done automatically after
termination of application?
All your application memory is freed when the app quits.
If I try to dealloc objects which
should be deallocated according to
instruments, My application
terminates abnormally. If I don't
dealloc, My application runs
perfectly, How?
Here I can't help, you really need to read more on the retain/release memory cycle... if you release an object that has a retain count of 0, the app crashes because the object is gone.
Why it is suggested that you wait in
a view up to 10 or more seconds, if
there is a leak, leak will be
detected by Instruments?
Because instruments works by sampling memory every so often, so it might take a little bit for instruments to get around to reading the memory after an action.
First of all, the things in the stack are colored by which library they come from, so it doesn't contain that much information.
Second, instead of worrying about how much leakage the iPhone can take, I'd focus on not having it leak.
To find leaks, there are a couple options:
Use the CLANG static analyzer when building your project
Look for leaks manually. You must always follow The Rules of memory management: if you alloc, retain, or copy an object (including using #property (retain) or (copy)), you must release or autorelease it.
The colors represent the different libraries the call stack is going through.
The leak is caused by the frame in your code that made the allocation, even if the actual allocation is taking place deep within an OS library. Instruments is showing you exactly where the leaked memory was allocated. You'll have to figure out which line in your code resulted in the leaked allocation, which will be one of the frames in the stack on the right.
The actual iPhone doesn't have much RAM available to your application. I tend to conservatively estimate about 25MB of RAM for my application to work with. Any leak, no matter how small, can sink the proverbial ship if the code is used enough.
Look for your application name in the stack extended view. Memory allocation usually shown in the end, so you know exactly which library is responsible for memory allocation. So you should trace from the line your code appear downwards till the end. Colors just make easier to trace lines of code, that are related to same libraries. Same library calls will be colored with the same color.
As for tracing leak itself. First go to your application call by double-click on the line in extended view and try to understand what exactly leaks. Sometimes you can replace the leaking call with non-leaking substitute. For example, I used a call imageNamed to retrieve images from the bundle, the application was constantly crashing because of memory shortage. I just googled imageNamed leaks and found very useful article on how to implement image cash in my application. Indeed, imageNamed API leaks. There are API that leaks in iphone SDK.
Also, try to check how you're working with alloc/retain/release and so on, whether you release or autorelease your allocated memory.
Good luck in your detective work.
I too have problems with leaks in instruments. I run my app today for the first time using leaks and found several leaks. Leaks that shouldn't be leaks because there is no way for them to leak, unless some magical code is executing and raising the retain count of my objects. I understand the memory management guidelines, know how to use autorelease pools, etc. But even an empty view based app contained leaks if i put a few controls on it. And just click around 2-3 times. Go ahead and try it. I don't really understant the information instruments is trying to provide. Are those "leaks" really leaks, or just things that are suspicious to the instruments app? Should an empty app with no user code, only a few controls put on an empty view leak memory?
I need lessons in memory management. I have an application that uses multiple views (around 10), some of these are attached to tab controller. Problem is that I'm using images (many images that I load from a web service). I'm facing the following issues.
The memory keeps increasing when I scroll in the table view (why?) - I checked the CustomTableViewCell application from Apple's site, and it's showing the same signs when I run it with Instruments.
I'm using autorelease with many objects, but I see that these objects don't actually get released and the memory is wired. How can I get rid of these objects?
How can I tell the NSAutoreleasePool to periodically release the objects that are not being used? I think this can help me get rid of wired memory. But can I do that?
Is there any example by Apple or someone else (book or online articles) explaining how to use Instruments (in a little detail with example?) and to fine tune the application for memory and performance?
Thanks.
Now that we have the "just say no" answers to autorelease out of the way, I thought I'd add a tip on how to use autorelease more effectively. For better or worse not everyone's going to completely avoid autorelease-- if for no other reason than because Apple provides so many convenience methods that hand you autoreleased objects.
You can't just tell the autorelease pool to free up any objects that you're not using. There's no garbage collection, and how else is it going to know?
What you CAN do is to create a local autorelease pool and then release that when you no longer need the local autoreleased objects. If you have a block where you're creating autoreleased objects, you'll ensure they get freed by creating a local autorelease pool at the start of the block (just alloc/init it, no magic required) and then releasing the pool at the end of the block. And voila, and objects in the pool are also released.
Autorelease pools nest, so keep that in mind if you do this. If you release an autorelease pool, make sure it's the most-recently-allocated pool and not some other one.
The autoreleased memory is released when control is returned back to the system, but only when it chooses to. If you wish to force memory to be released use "release" which works there and then.
It should be noted that because of memory fragmentation that allocating and deallocating a block of memory may not seem to get you back to where you started in terms of measurable "free" memory.
Tony
For performance reasons, Apple recommends that you retain/release objects yourself whenever possible. autoreleasing them can cause excess memory usage as the autoreleased objects aren't always released immediately.
In other words, if you know you're done with an object, explicitly release it.
The UITableView has a way to reuse table cells that aren't being displayed anymore. That way if you only display 6 cells on the screen at once it doesn't keep on creating more as you scroll, but reuses the cells that have gone off screen. whenever you want to create a new cell, first query the tableview to see if it has any to reuse and if not then create a new one.
an example of this can be found on slide 55 of the standford iphone course note found here: http://www.scribd.com/doc/7671058/Standford-CS-193P-11Performance
According to Apple, you should not use autorelease and instead should retain and release objects explicitly as needed. autorelease will not release an object as soon as its function is over. If in the tableview you are using images downloaded from a webservice, try and cache these images and reuse them if possible. Another option is to only get those images which are being displayed.