I am running the Instruments Tool (Leaks) and am receiving memory leaks in the QuartzCore library and don't know exactly where in my code this is occurring. Usually I'm able to pin point the line where the leak is occurring, however the instrument tool isn't giving me anywhere to view this type of information.
What would be some other things I could look at in terms of diagnosing such a leak?
First, try running this on the device. Sometimes the simulator will report leaks that do not exist on the device.
Secondly, open up the stack trace (right sidebar) and see what code of yours might be involved higher up in triggering this call, then you can think from there why that code might be leaking.
One additional bit of advice. Instead of playing with leaks there, switch over to ObjectAlloc and use the Heapshot feature - if you know about where the leak is, use the heapshot to set a base memory measurement and every time you hit the "heapshot" button after that you'll see a kind of memory "diff" against that baseline you set. Solving any over-retained problems might also fix your leak.
If you’re only leaking 16 bytes at a time, it’s really not likely to become an issue in your app. And if the leak is occurring in a system framework, it probably isn’t your fault.
Related
I have run my app with instrument and i m getting a memory leak but i dont know at which point that memory leak is happening.
How will i know at which point memory is leaking.
Check out this article "Actually finding a memory management error with Instruments", from the big nerd ranch. Creating "heapshots" is a good way to start narrowing down the code parts that show no obvious memory management errors at first glance. But as ACB stated already, if a system library is leaking (rare case) there's not much you can do about it. But most of the time the memory issue is always in your apps' code somewhere! :-)
It says responsible library is quartzcore, and it is only 16 bytes. As long as it is not in the app and the OS is causing the same, you cant do much about this. I would recommend you to ignore this.
If you are facing issues, check the allocation tool -> Live bytes section and check if memory is shooting up when you are selecting a lot of images at the same time.
I can see from your screenshot that your app is already running in your device/simulator and you are trying to run it again with instrument, try to close your app completely from device and then start it again with instrument.
You can read more details about Xcode instrument from Apple.developer InstrumentsUserGuide
Also I have found another good tutorial about this in Raywenderlich blog
Another good documents is here
I fixed memory leaks of my application using
X-Code->run with performance tool -> leaks
I submitted my application and later I analyzed my code attaching to device like Build & Analyze for device i got many Potential Leaks popped up when i pressed Product then cmnd+shft+B.
What is the difference between the two, was my fixing of leaks based on instruments wrong?
Is it like some leaks pointed by analyzer may actually cause leaks which are not shown/caught by Performance tool?
When you run the leaks performance tool it will let you know WHEN a leak actually happened. Build & Analyze warns you of potential leaks that COULD happen while your program is running.
Your fixing leaks based on instruments was not wrong, but you should also carefully look into the leaks build & analyze tells you, as they could potentially leak when the program is actually running.
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 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.