I tested my app with the Leaks tool to determine leaks. I resolved all leaks but one.
This one seems difficult to remove. I am working on it but not sure what will remove the leak.
Is it normal for apps to have one or two leaks which don't leak that much memory over the usage of the app?
A memory leak is a bug much like any other bug. They are very easy to measure, though, and in some situations they can cause fatal crashes, so a lot of effort is put into dealing with memory leaks.
But most apps, memory leaks or not, have bugs in them. And a bug isn't automatically a blocker just because the bug causes leaking of memory.
Related
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 new to memory management and have been playing around with Instruments in Leaks mode. This is my latest output and I was wondering if I could get some feedback from the SO community. It seems as if my total leak amount is quite high, even though the individual leaks are not that big (I think). Should I be concerned? Should I be looking to get rid of all of these leaks?
N.B. The app runs on the iPhone and doesn't use any network.
The screen you are looking at is not the Leaks. It is the memory allocations of your app.
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 :(
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 testing a particular use case for leaks. Sometimes, I get the leaks and other times I don't even if I go through the same usecase. Can you suggest whether it is because of the system frameworks or my code?
I have checked in my code and everthing looks perfect without any unreleased objects. Can you suggest a solution?
Thanks
It's extremely unlikely to be the framework. Don't forget that there are hundreds (thousands?) of developers out there using it so the chances of someone not noticing a bug there is rather slimmer than code that's only been reviewed by yourself.
The most likely source for an intermittent memory leak is autorelased objects. Autoreleased objects hang around until the autorelease pool to which they belong is drained. Depending on memory conditions, they may look like they're leaking during one run but then they don't the next run.
See Avoiding, finding and removing memory leaks in Cocoa to learn how to track down memory leaks.
Edit01:
You might get away with it but I wouldn't recommend it. If it leaks while Apple is testing it you stand a good chance of being rejected.
As a quality issue, it depends on how bad the leaks are and how long they can go on during real world use. Every app probably leaks a few bytes here and there. (For example, there are known leaks in some of the frameworks.) If the leaks are very small, they won't cause problems especially on an app that only runs for a short time. However, if the leaks are larger or the app is designed to run for a long time, then the leaks will eventually bring the app down.
For example, suppose you have a program like the weather app. As a quality issue, it really wouldn't matter if it leaked a bit because the weather app is used quickly. People open it, look at the weather and then close it. The leaks don't have time to accumulation. On the other hand, if you had an app like a web browser or a eReader which people leave open for long periods the leaks could accumulate and bring the app down.
In short, like all other programming task, tracking down leaks is a tradeoff between perceived quality versus development. It is very common to spend more resources tracking down a trivial but common bug than to track down a serious but very rare one.
I would reiterate that the memory leak detection methods in the leak above will eventually locate the leak. If you spend the time on it you will eventually find it.