I am wondering is there a way to find out memory allocations that dont get deallocated on iphone application exit or it's termination .
I have been using instruments fixed most of leaks that I had in my application, but i am worried that there are still some allocation that i didnt release.
Thanks
In short, don't bother trying to find and fix leaks caused during application termination. It is quite likely -- almost guaranteed -- that neither Cocoa nor the iPhone frameworks try to release all memory on termination as doing so is entirely a waste of CPU cycles.
If you are going to hunt down leaks, do so through using your application as your users do, keeping an eye on the Object Alloc instrument's analysis.
What can be useful, though, is putting a hook in that is triggered before termination is an absolute. Stop there and make sure the app's object graph is as expected.
No need to worry about cleaning up memory on application exit. The operating system will wipe out any memory allocated to your application at that point.
but if you use opengl please clear out your buffers :P.
Related
If my app uses less than 10MB do I have to bother to use those methods? I know that they are for caching low memory situations but this might occur only if you do not tested you app before releasing it. If you have tested your app, the app does not have leaks, have a small memory footprint, then why should anyone bother to use memory warning methods?
Your app is probably not the only thing running on the device. Other apps and processes are also taking up memory, and in some situations they may need it more than you. It's always a good idea to respond to memory warnings by releasing cached data that can easily be loaded again. That way the operating system has control over the memory usage, and it won't have to terminate your app.
I'm in big trouble now, my iPhone application keep terminating again and again due to memory leaks and I am unable to judge that where are those leaks. Tell me what step can I take in order to resolve this problem.
Thanks
You can use Instruments to see where potential leaks are.
Here is a good tutorial. http://mobileorchard.com/find-iphone-memory-leaks-a-leaks-tool-tutorial/
I think you're confusing terminology here. A memory leak is when you don't release an object after you're done with it.
A leak won't directly cause a crash. Leaks can indirectly cause crashes if you run out of memory as a result of not releasing lots of objects. However, if your crashes are happening in the simulator as well this is almost certainly not the case (the simulator having far more available memory than the device). As Daniel says, you can use the instruments tool to find out what's leaking.
Another good method is to use the XCode static analyzer - you can have it analyze your code and detect most common leaks.
Now, if your app is crashing and it's not because of a memory leak (you'll be able to tell this because you'll have memory warnings outputting to the console) then chances are your problem isn't a leak. Perhaps it's a bad access (you're over releasing), in which case your instruments leaks tool isn't going to help you.
If you need to find out leaks and source of crash. you can try these
try to find as many leaks as possible from Instruments and fix
set NSZombieEnabled for your executable parameters and debug application crash
change all your autorelease objects to use alloc init as much as possible.
--
worst resort is if it keeps crashing even after trying all the above three. you write memory intensive module of your code in a thread and clean up that thread. I've noticed usually when threading is done the memory footprints are much cleaner. This is just my opinion, but the above 3 you should do.
You could also Build + Analyze your application in XCode itself (Cmd+Shft+A or Product > Analyze). It'll show you the more obvious leaks.
I have an application under development that uses a large amount of memory for images and OpenGL textures.
I have noticed that occasionally, in fact frequently on some devices, SpringBoard, the application which manages the home screen for the iPhone and iPad can take up excessive amounts of memory, sometimes twice as much as normal.
When this happens, it sends my application in to memory warnings and even crashes. My images do get released as soon as possible, but I believe that due to the sheer volume, it simply isn't good enough and still results in crashing...
I can't find much in the Apple docs about SpringBoard, but it's pissing me off.
Any ideas or pointers on figuring out what causes SpringBoard to be so aggressive?
Your application shouldn't crash in these situations -- it should shut itself down gracefully when the OS tells it to quit. Apple won't document Springboard very much because there's not much they can tell you about it that should affect what you do as a programmer, which boils down to "use as little memory as possible; don't leak memory; quit as quickly as possible when told to quit".
In short, if you're spending any more time worrying about Springboard's behaviour, instead of fixing the crashes in your app, you're not using your time wisely.
The answer was that MKAnnotationViews, despite being autoreleased, were pooling up in the memory footprint of SpringBoard, as opposed to my own app, and were not manifesting themselves very clearly in Instruments.
This is a fairly deceptive thing on Apple's part, particularly in that they allow you to autorelease and never use an object, but it will never actually be released... therefore it is technically not a leak in the eyes of Instruments and static analysis, but can still easily lead to memory related crashes.
I'm reading up on the leak-finding tools for iPhone development and intentionally inserting and looking for memory leaks in my small program before I get into a bigger, harder-to-debug project.
It's no problem to identify a memory leak that, say, occurs in a regularly invoked method like responding to a touch event. The leak instrument will eventually identify virtual memory that is unclaimed.
I'm more worried about a leak in code for exiting the entire system. Once I completely exit my app, is it a concern that something wasn't deallocated, or does iphone OS automatically reclaim all user mem at that point?
This issue is unclear to me after reading quite a bit of documentation, and without knowing anything else, I assume it must work like other OS's in that regard and just take back all user space. If that's so, won't I be fine cleaning up regular leaks so my app can run for any amount of time with bounded memory, then not worry so much that everything gets freed up at exit?
Also, if it is critical to free everything before exiting because it will not be reclaimed by the OS, is there a good way to keep my app alive in the instruments after exit for inspection? When I press the home button in the simulator or on the device haven't I already lost the chance to detect exit-time leaks?
Yes, ending your program will release every bit of memory held by it. Anything otherwise is an OS bug, and you're unlikely to find that occurring.
EDIT: I bet your asking this because documentation says "iPhone doesn't support garbage collection." That statement, however, doesn't apply to freeing memory when a program ends. It's only talking about how you have to handle freeing your own memory while your program is running.
The iPhone should be using virtual memory, so (theoretically anyways) the OS will clean everything up when a leaky app exits.
I'm afraid I introduced a memory leak or something to version 1.2 of my iPhone app. When I use 1.2 version I notice that my battery drains a lot quicker then with 1.1 version. For comparison, with 1.1 version the battery would last whole day and still have plenty of juice in the evening but with 1.2 I find that I have to plug it in mid afternoon.
Would a memory leak (or a lot of them) cause an increased battery drainage, or do I have something else going on?
The only interesting thing my app uses is AVAudioPlayer class to play some caf audio files. Other than that it's just couple of views with a table view.
I do call AudioSessionSetAcvie(false) in my applicationWillTerminate method, so I don't think it's the audio session that's causing this. I don't have to have my app active for the battery to get drained. It's enough to use it for a while and then exit. So I'm pretty sure I'm leaving something behind, I'm just not sure what.
I tried playing with Instruments tool, but it looks like you can't used with the app running on the device (for some reason my app stopped working in the Simulator)
Any ideas on how to go about finding what's causing the battery to drain?
Memory leaks will not cause increased battery usage. However, if a memory leak persists, eventually you will get a memory warning, and if you can't clean up enough memory, your application will be killed.
Increased battery utilization usually means something is causing your code to continue running. The best way to tackle this problem is to run your application under Instruments (with Sampler probably) and let it sit there in the state that you're confident it usually runs the battery down. Inspect the results of Sampler, and if you have code running, you'll be able to see the stack trace for it.
Hopefully once you've located what code is running, it will become apparent how to stop it.
Memory leaks won't cause increased battery usage, as Nilobject says.
I would try commenting out various areas of functionality, one at a time, to try to narrow down the area that is causing the problem. In your case, the first thing to try is obviously to remove the audio. If, once you've done that, battery usage is back to normal, you know where to look more deeply.
(for some reason my app stopped working in the Simulator)
I would fix that and use instruments to fix the performance bug. It's never a good idea to fix the difficult defect and leave the easy one.