I am developing an iPad app and found some memory leaks using Instruments and Analyzer. I tried to release some objects which resulted in the crashing of my app.. Are memory leaks allowed in an app? If so, until what extent they are allowed? Is there a way to completely remove the memory leaks with out the app getting crashed??
Generally speaking, it is possible to make sure that the code which you write is leak free. This is not to say that Apple frameworks and internal libraries won't leak at all.
If you call alloc, new or copy make sure to call a corresponding release or autorelease. Apps that leak a lot are bound to crash often. Apps that crash often are likely to be rejected from the App Store.
Please read this. We can create an application with 100% leak free. Enable NSZombieEnabled to check why the crash occurs.
It's best to remove as many leaks as you can.
But if there are a few remaining in your application that you can't remove, Apple will still accept your application - as long it doesn't crash frequently.
Just make sure when you alloc something - it's released with release or autorelease.
That's the best way of making sure leaks don't occur.
Leaks are much, much easier to not have in the first place than to try plugging later when the app has memory issues. Fortunately in the iOS/Cocoa world the memory management rules are clear and simple. However as others have said there could be leaks in code you didn't write :(
Related
I am implementing an iPhone application and when I ran this app initially it was showing memory size was 5.3MB
and after 10 min it was showing memory size was 185.3 MB.
I'm releasing objects manually and also analyzed my app, I have only one memory leak(that to return object in class method). What was the problem? is it harm to app while apple approve it?. Please help me. Thanks in advance.
No, you really shouldn't release it with this kind of a leak (or memory accretion). It will lead to crashes and that will cause data loss and upset users.
Heapshot analysis is designed to track down these kinds of problems. That is, use the Allocations Instrument to track memory growth over time iteratively and then eliminate the large memory consumers.
Apple will probably approve it as long as it is not crashing within the review time.
But no you should not release the app if you have a memory leak like this. Your app will have poor user experience and might crash if the users device memory runs full. You will get a low app store rating.
I would suggest you find out which object is taking up so much memory and fix it. If at all possible switch to ARC, this will take away some leaks.
I have same problem too. NSZombieEnabled flag work for me. I think this might be helpful to cope up with ARC. I have followed this link: How do I set up NSZombieEnabled in Xcode 4?
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'm checking memory leaks in my apps using Instruments Leaks tool.
After fixing all leaks whose responsible library is my app. I figure out that there still have a lot of leaks whose responsible libraries are iOS's framworks, based on what Instruments said?
This is a screenshot of Intruments:
I think these leaks may be caused by some of my misuse of frameworks' methods.
What is your approach when getting leaks like these?
Thanks!
Well Apple Developers are also human, and they also can make mistakes. Alternative would be to create your own framework exactly same to that of Apple's but that will not be nice thing to do as Apple will certainly come up with upgrades and fixes in future that will resolve the issues.
The only solution would be to report bugs to Apple about memory leaks, even I have seen that framework has lots of memory leaks.
There are also other reasons for memory leaks, instruments may show memory leaks in apple's framework, but it is not necessary that it is caused by the framework's bad code, indeed it could be the bug in our code where we did not follow correct steps, for example we add observers but we do not remove them, we bind for events but we do not remove them, so if we have not done cleaning operations correctly, instruments may show leak but somewhere else.
I've been noticing the same with one of my apps and in the end, after trying to figure out what I am doing wrong, I came to the conclusion I'm doing nothing wrong and that Apple's frameworks have memory leaks as well.
So I don't think there's anything you can do.
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.
So, I finished writing my first iPhone App, and I have sent it out to a group of beta testers.
Everybody is happy, except for this one guy who noticed that after having run my app, another app is not starting up anymore.
Not knowing too much about memory management, I started looking at the Leaks graphs in Instruments, and noticed, that there are some leaks going on in my app.
Three questions:
Are leaks always bad? The biggest leak is 15k on a total of 5,1 MB allocated memory.
Will Apple refuse my app because of leaks?
Is not all the memory automatically freed up as soon as my app quits? Could it be that my leaking app is harmful to other apps?
Thanks
Sjakelien
Each app is supposed to run in its own "sandbox," and is by design not supposed to affect any other app installed on the phone. If your reviewer found a case where your app really did affect another app, that's definitely not your fault, although I'd love to know how that was accomplished ;).
My guess is, though, that your reviewer's other app broke completely independently of your app, and he/she is spuriously attributing the fault to your app. Ask him to try to reproduce the problem (uninstall both apps, install the other app, install your app).
what the other two answers say i agree with, however nobody has answered the first question ("Are leaks always bad") directly. i would say that yes they are. it's true that your program can possibly run with them for long periods of time without issue. and the OS should clean up the memory after termination (unless there's a bug in the OS, as said before). but eventually the leak will become an issue for someone at some point when they run long enough. also, even if it doesn't become an issue, it's probably a best practice to always fix memory leaks that you know about.
Any leak that persists beyond the exit of your application is an OS bug, and hence Apple's problem.
It would be unfair to reject your app on this basis.
I don't know if that's any comfort to you.
For the record, my app provokes a leak in mediaserverd.
The leak is a tiny bit smaller in the 3.0GM.
Another incorrect usage of an API crashed mediaserverd.
Also 3.0GM. Nasty. I'd have preferred an error code, however
this could theoretically be used to work around the leak.
It depends on what "memory" you are leaking. Are you using device storage space to cache something? In theory then it's possible that you've used up enough space the other app cannot start because it needs a certain amount of free space.
If we're talking physical memory, then no. When your app is dead it is dead. You could ask them to restart the device and see if they have the same issue.
Apple does approve apps that have memory leaks.
That said, we thoroughly check that none of "our code" leaks before submitting to Apple because users don't like having an app suddenly shut down on them. I say "our code" because there are memory leaks in the framework that are not your doing. Thus Apple approves apps with memory leaks.
Also, I am doubtful your app has adversely affected the user's other app. I have not seen that behavior.