I tried to profile an app with Instruments to see how much memory the app is using and whether there are some leaks.
After tweaking it a little bit, I got rid of a couple of leaks and now it's not showing any. However, I noticed that every time I push some view controller and pop it back, the memory goes up, then a little bit down, but not to the level before the push, e.g. Live Bytes showing
1.8 MB before the push
2.1 MB after the push
2.0 MB after the pop
2.1 MB after second push
The funny thing is, after pushing it second time (or even 10 times) it doesn't increase over the previous value, so although it looks like a leak, it's probably some kind of a cache or something. I first thought it's something specific to my code but then I was able to reproduce it pretty much with any view controller, no matter how simple the content happens to be.
Is there a reasonable explanation for this phenomenon or am I just doing something completely wrong in all the examples that I have built ?
Thats happens b/c of autorelease pools, and memory that is suppose to be released for you. It stays for as long as it needs. When you push more viewControllers on the stack more autoreleased objects are created. Some of them will be released earlier the others, but it will very in time, so your memory fluctuation is normal.
Related
I'm going through the Allocations instrument, trying to clean up my admittedly terrible memory use.
As per Apple's advice, I take heapshots while repeatedly performing an action, to make sure the memory is freed up. For the most part it works well, but I'm stumped by this one:
It's a 464KB allocation somewhere in CALayer display, that never gets cleaned up. The worst part is that it's inconsistent - it doesn't happen right away (in this case it happened on the 10th iteration of my repeated action, and the number varies). The usual heap growth per action is under 20KB (still cleaning that up), but this one really stands out. I can't find any pattern for when it happens, or why.
How can I track it down?
That is about how much memory is needed to back any full-screen UIView's drawing layer if an app does any drawing into that view. You can't clean that up as long as that view is allocated and showing.
I have been hunting down memory leaks for some time in my app. As of right now, as I flip back and forth between two views while watching the memory monitor instrument, the real memory fluctuates between 5 and 6 megs. This is all fine -- as far as I can tell everything is getting released properly when I pop back off a view. However, the virtual memory continues to increase and my available real memory drops rapidly every time I push the view back onto the view stack (even though the real memory usage of the app isn't increasing). Eventually, this all leads to an out of memory crash. Is this a telltale sign of any specific issue, or am I just missing a memory leak somewhere?
EDIT: The odd part is, I get an out of memory crash while the app is still only using up about 5 megs of real memory.
Do not use -retainCount.
The absolute retain count of an object is meaningless. It is an implementation detail. It may be influenced by many factors well beyond your code.
You should call release exactly same number of times that you caused the object to be retained. No less (unless you like leaks) and, certainly, no more (unless you like crashes).
See the Memory Management Guidelines for full details.
In this specific case, you are leaking memory but in a way that leaks can't find it. The objects that are leaked are still connected to your overall application's object graph somehow. Maybe through a notification, maybe through delegation, doesn't matter -- leaks sees the reference and concludes that the object might still be live.
Use the Allocations Instrument. Configure it to only track live allocations (since you don't care about objects that have been deallocated). Do some stuff with your app. Check out what Allocations knows about and explain why all those objects should stick around. You can use the data mining facilities to filter down to just your objects.
Anyway, you can also use the "Build -> Build and analyze" option to find suspicious non-conventional code.
Another reason why you may have memory lost in lower API layers is if you don't remove all your views from your view hierarchy (aka : not calling [view removeFromSuperview] everywhere). At least that's what seemed to have happened to me.
Note that most of time this isn't required, as you would simply release the main view and all its subviews, then rebuild it from the view controller when needed. Things start to get more tricky when you're not releasing the whole hierarchy but instead simply remove some of them from the hierarchy.
In that case, I came to the conclusion that you may have buffers or layers still cached in lower API parts, and in that case your Allocation instrument won't help you.
In order to monitor correctly you'll need to use the "Memory Monitor" (in System). You'll see that the "Physical Memory Free" line dropping close to 0 is the most reliable indicator that a Memory Warning will be issued.
Another advantage of using this instrument, is that you can attach it to a running process, thus making it possible to have console output and instrument running together easily.
Circular references also won't be counted in Leaks but you can track those in Allocations. Best bet is to fire up Allocations and get to a state where you think everything should be gone (or certain objects should be). If they're hanging around go dive in to them and look at where they've been retained and sort out the proper memory ownership/releasing.
As for Allocations, there are some things that it doesn't track that can affect the overall memory. Some of the things include some CGImage backing stores, some CoreAnimation stuff and some database stuff.
Have you used the "Leaks" Performance Tool? And check out the logs in Organizer to see if there's anything there.
Also look into the dealloc for the view controllers and make sure you are properly releasing all of it's objects?
I'm using Instruments with the Allocations instrument. I'm testing only a fixed interaction with my app.
I have a navigation controller which goes 4 stages deep. The first two stages are standard table view controllers and the last two are custom controllers with dynamically loaded images.
So I run my app in instruments (via Run with Performance Tool -> Allocations) and do the following interactions:
1. App Loads
2. I wait a bit until allocations graph stabilizes
3. I tap/push into my navigation controller until the deepest level.
4. I wait for the images to load and for the allocations graph to stabilize.
5. I tap back out of the navigation controller until I'm back to the root level.
6. I wait for the allocations graph to stabilize.
7. GOTO 3.
Now what I've noticed is that between each iteration from 3 to 7 the allocations graph shows a slightly higher value. So the overall allocations are increasing even though I'm doing the same thing and all the view controller's deallocs are being called.
So the timeline looks roughly like this:
1. Start: 1mb
2. Push controllers/Load images: 4mb
3. Pop controllers: 1.1mb
4. Push controllers/Load images: 4.1mb
5. Pop controllers: 1.2mb
6. ... etc ... (always increasing slightly)
So my question is does this mean I have a leak or is this normal? Also what does the allocations graph data actually represent? And why is the value increasing even though I'm popping back out to the initial state? I'm worried that if my app runs long enough it will consume too much memory even though all the user is doing is pushing and popping view controllers.
Any thoughts would be helpful.
Is this in the simulator, or on the device?
As it's good to verify a problem exists on the device, as some system libraries release memory more often on the device than in the simulator.
If Leaks shows nothing, it's because you are still holding a reference to memory somewhere even if you don't think you are. To help track that down, highlight a small portion of the graph where the memory is increasing, and select "created and still living". Now you can see just the memory allocated, and start to track down just where the issue is.
If you have the newest iPhone SDK, the version of Instruments it comes with (2.7 I believe) has a HeapShot feature. You can watch some of the WWDC '10 videos for more information, but essentially you take a shot the first time you pop controllers and then again when you pop a second time. It will show you any memory allocations that are different at the two moments.
You probably have a leak. Check the leaks instrument which can help you find them.
Yes, this is a leak. One of your view controllers along the line is missing something.
If you are loading images then there is a good chance you are using [UIImage imageNamed:] that causes the system to cache and may be a cause of your memory use. But in short yes, you have a leak.
I have an app that has a tabBar Controller and a navBar Controller. It has ~8 views (a variety of web, table, standard, mail, address etc.), some created using IB some created using XCode to make the table views. I've ran the memory leak tester and it doesn't have memory leaks. It can crash at anytime on any of the views, If I flip back and forth between views and use some of the functions it closes the app.
I assume that either I am running 1) out of memory or 2) not releasing views correctly, which causes the app to close. The app is simple so I don't know how I could be out of memory and I've reviewed the code to the best of my ability for releasing the objects correctly.
So Here is my list of questions:
1) What and How to use some of the other debugging tools (or tell me what tools/files I should be looking for using)? I would like to narrow down the problem to its source.
2) What is the best practice for releasing these views? How?
3) How much memory do normal apps use? Is there a number that I should stay around? How do I verify that in the simulator? the Allocation tool?
Feel free to point me to apple docs or other stackoverflow questions that can help me.
UPDATE: It appears to only be crashing one view is used, which has a table view with custom cells... The cell are populated from a plist file... this view worked fine a few days ago, I notice that some cells do not have data from the plist file... it could be a plist file problem with not storing proper data. I'll continue to work on it.
UPDATE #2: I went back to older rev of my files, to when this particular tableView worked just fine (pre 3.0) and guess what it works just fine, I change the simulator to 3.0 with this rev of the app and bam crash on this tableView shows up. Thanks for the help so far, I'll try somethings mentioned below and let you know what I find. If you have some tips on why a tableView w/custom cells from 2.2.1 to 3.0 would start crashing, I'll take them. If I can't get anywhere I'll post the code soon. BTW, I mis-spoke above, I thought it wasn't crashing in the simulator... I was wrong it is.
Solution: thanks for the troubleshooting tips the fix was quite simple, but it's odd it didn't crash in 2.2.1... it should have crashed a long time ago for the problem, I was releasing an object one to many times in my custom cell... duh.
On the first and second generation phone's you really don't want to be going over about 20 megs of real memory usage - once you get over that you are at risk of being killed by springboard.
One of the big culprits I've seen is autoreleased memory, since the autorelease pool can hold onto memory a lot longer than you would really like - if you are using a lot of autoreleased objects that can be a potential problem. You can improve this by doing more explicit retain/release where possible and by creating local autorelease pools manually and releasing them after doing a more intensive operation with a lot of autoreleased objects.
The most effective way to keep track of real memory usage I've found so far is running a debug build on a test phone and running with Activity Monitor. That will give you a clear idea of how much memory is getting taken and held onto by your app. As well as how much is being used when it crashes on you.
You can run with Activity Monitor in Xcode on the Run menu -> Start With Performance Tool -> Activity Monitor.
One other very useful tool is the CLang Static Analyzer that you can run against your code base and can give some very helpful memory management information. As mentioned here.
One thing I would try is putting some debug messages into your didReceiveMemoryWarning method(s). That way, if you are running out of memory, you'll at least have some warning.
I've been able to replicate a bug consistently on an iPhone app I'm working on. The bug always follows as soon as my UIViewController's didReceiveMemoryWarning method gets invoked. Some of the issues I'm seeing are as follows:
UITextField's text property niling out.
The previous data in the UITextField is getting appended to a string multiple times, thus giving me corrupted data back when I HTTP to the server
This happens as soon as my breakpoint on didReceiveMemoryWarning hits, otherwise all appears to be working just excellent. My question is, does it sound normal for this odd behavior to occur during a memory leak? If so, what is happening with the UIViewController that's causing such ad-hoc duplication of data in a previous UITextField (which is a part of a UITableViewCell's contentView, so I figure there's some oddity going on with dequeueing of the cell)
It's interesting none the less.
Thanks!
When the iPhone runs low on memory the OS tries to intelligently do things to reduce memory overhead. In a few cases I've seen this cause odd behavior such as text content go missing or a keyboard failing to display.
However you may want to focus on finding the source of your memory problems instead of the results.
Usually, not very much, as long as your application is not using all the memory in the hardware. But memory leaks can stack up, and next thing you know you are out of physical RAM. You may see a sudden performance dip as virtual memory kicks in and parts of your app starting paging to the much slower flash disk storage. This is when your controller will likely get a low memory warning, and UIKit may remove some things it thinks you don't need (like views without superviews, possibly other thigns). Soon after that, the entire app will crash as the iPhone OS forces it to quit because it is using too much memory.
The short version: memory leaks lead to crashes. But the removal of object it thinks you dont need may cause some odd behavior as well.