While debugging my App with Instruments I found a couple of memory leaks.
I haven't done this since MRC, so forgive me if I'm missed anything obvious.
Going to the Cycles and Roots Section on the 'Leaks' instrument revealed many 'Root Leaks'.
The call tree is empty. All the leaks say "Malloc X Bytes [no ivar] Malloc X Bytes" and nothing more. (There's a graph on the right showing this too)
How would I go about finding the cause for these memory leaks? I haven't written all the code so It's difficult for me to find the exact code that causes this.
Since they come up under 'Cycles and Roots', does this have anything to do with retain cycles? Could they be a consequence of not nulling out blocks correctly?
I'm Using ARC, Xcode 4.6.3, Instruments 4.6 and the iOS 6.1 Simulator
Related
Now i'm developing iPhone app but it seems happen memory leak. I found by Instruments:
I have question:
-- how to find where is code that happen memory leak about "Malloc xx bytes"?
-- I think I can't improve memory leak in Library. Example for "Foundation", "StoreKit" and so on, right?
Switch to the call tree view to find the areas of your code allocating the leaked memory. For more detailed information, see my answer to the following question:
Unable to track memory issue
Also for clearer representation of memory leaks select Allocation tool, go to File>Recording Options and tick "Discard events for freed memory".
In this way all the spikes that you will see in the chart will be actual unfreed memory
I've tried to read almost every decent tutorial in the internet, but still can't understand what is really happening here:
I've "Hide System Libraries" and "Invert the call tree", but I do not understand how to find actual code responsible for for example this leak. Any tips are appreciated. May be I am missing something obvious. I am getting hundreds of leaks, however I am using weak in closures, I do not have classes referencing each other etc. But it looks like I am missing something fundamental.
The problem shown in your screenshot is Instruments can't find your app's debug symbols. Instruments is showing memory addresses instead of function names. You are not going to be able to find the source of your memory leaks in Instruments without function names, even if you invert the call tree and hide system libraries.
Make sure your project is generating debug symbols. Check that the Generate Debug Symbols build setting is set to Yes. If your project is generating debug symbols, Instruments may be unable to find the dSYM file that contains the debug symbols. In Instruments choose Instrument > Call Tree > Locate dSYM. The dSYM is usually in the same directory as the release version's application bundle. The following article has additional information:
Instruments: Locating dSYM Files
Memory leaks can be difficult to track down. This is likely going to be a time consuming process, so be prepared. In the end, there is usually a lot of trial and error with debugging memory leaks. The "Memory Leaks" instrument has actually only detected one leak for me in the past. I've always had to track them down myself using the "Allocations" instrument.
One of the things that has helped me in the past is to start by trying to figure out what objects are actually being leaked. Click on the allocations instrument (the row above "Leak Checks"). Now try sorting by number of objects released or amount of memory used. See if there are any objects that have a count of 0 released when they shouldn't be sticking around. See if there is an object type that is taking an abnormal amount of memory.
Memory leaks are always due to developer mistakes with memory management. There are some minor memory leaks that exist in some of the lower level private APIs in Foundation and UIKit. At those lower levels, they are dealing with a lot more manual memory management, so its much easier to make tiny mistakes. You can't really do anything about those, but they are relatively rare.
If your application is working just fine, you may not need to worry about fixing these. There is some cost benefit analysis you want to do here. If this isn't impacting performance or stability, is the time investment in fixing these right now worth the minor benefits it will provide you and your users?
However it is worth nothing that memory leaks can add up, so if a user has your app open for a long time, the amount of leaked memory will eventually become a problem if you continue to leak more objects over time. At some point the application will crash and the user will have to re-open. But if your memory leaks are small enough that this doesn't become an issue unless the app has been open for HOURS, is it really that much of a problem anyways? That's always a judgment call on your part.
I have spent few days working on this issue. That my app is getting crashed in iPod Touch due to Memory leak.
I have monitored heap growth exactly by Instrument in Xcode and it is confirmed that code is making memory occupied by app grow on each event.
I need to mention here that I am using ARC and hence i was really not expecting app to crash because of memory issue, although ARC isn't helpful incase Core foundation is used but I haven't used Core foundation in my app directly.
But MBProgressHUD is added in my app which uses this framework. I have not enabled ARC for MBProgressHUD as it was causing lot of memory grow.
I still am unable to track the main problem/variable/code which is causing my app memory to grow so much and causing app to crash.
P.S : Instrument had shown few functions causing lot of memory allocation but in those functions also I don't know how to free those variables as ARC is enabled (It is managed automatically).
Please suggest if I am in right direction.
Is it leaking or allocation is more? main cause for the app slow down is using too many number of autorelease objects.
as the title says, I have an app which works on iPad 2, but crashes on iPad 3. when running it the console gives me a low memory warning message. When the crash happens I symbolicate it, but there's really nothing that I can relate to the code, like it shows
process name, UUID, rpages, recent_max, [reason] (state)
and under those column headers just hexadecimal stuff, nothing showing method calls or lines in the project.
Any ideas? am I missing some flags in the code that allows for a better crash log?
Thanks.
If you're getting low memory warnings and fail to release enough memory to resolve the issue, your app will almost certainly crash. The thing is, I don't think that the particulars of how or why it crashed can possibly be illuminating. At that point, you're evaluating secondary symptoms. You really need to go back and figure out why you got the low memory warning in the first place and fix that problem.
As Daniel said, you can look at Technical Note 2151, but as it says:
When you see a low memory crash, rather than be concerned about what part of your code was executing at the time of termination, you should investigate your memory usage patterns and your responses to low memory warnings. Memory Allocations Help lists detailed steps on how to use the Leaks Instrument to discover memory leaks, and how to use the Allocations Instrument's Mark Heap feature to avoid abandoned memory. Memory Usage Performance Guidelines discusses the proper ways to respond to low-memory notifications as well as many tips for using memory effectively. It is also recommended that you check out the WWDC 2010 session, Advanced Memory Analysis with Instruments.
So, a couple of thoughts:
Have you looked for leaks? The Finding Leaks article walks you through how to use instruments to find your leaks.
If you turned on zombies, have you turned them off? Zombies is a great diagnostic tool, but just consumes memory.
Have you run your code through the static analyzer (shift+command+B or select "Analyze" on the "Product" menu)? Especially if using non-ARC code, this can find lots of memory issues.
Have you examined your allocations for unexplained increases without offsetting decreases with the Instrument's Allocations tool. Using that, you can run the program, look at the consumption of memory on the graph and see if you see any increases that aren't offset at some point by the corresponding decreases. And if so, highlight those increases in the graph:
For example, when running the Allocations tool, hold down the option key and then click-and-drag with your mouse to highlight a portion of the timeline, to identify what you want to inspect. You probably want to focus on one of your spikes in allocations. For example, I found a bump in my allocations and highlighted it as such (this was a ludicrously simple example where I create a huge array in viewDidLoad, but hopefully it give you the idea):
Note, I find it useful to show the call tree in the lower panel, it's often useful to select "Hide System Libraries", to focus on your code (and "Invert Call Tree", too). And if you double click on the method name in Instruments (in my example, here, it would be viewDidLoad), Instruments will then show you your code that's doing the allocation:
Low memory warnings generate a different kind of log than standard crashes. Take a look at the "Understanding Low Memory Reports" section of this article to understand what happened with your application and how you can debug it using Instruments: http://developer.apple.com/library/ios/#technotes/tn2151/_index.html
Instruments can visualize retain cycles under ARC in a graphically interesting way. I also remember that a few days ago I spotted the "Cycles" view in Instruments by accident.
Now where I started using ARC, suddenly I'm not able to find that anymore. The Allocations and VM Tracker instruments don't offer it, and the Leaks instrument either.
What must I do in order to see retain cycles?
Found a screenshot as evidence:
Using Xcode 4.2.1, I found the it in "Leaks", under "Cycles & Roots". However, I've found it less than useful when using ARC. It does detect CF leaks and apparently I'm leaking a recursive block, which I can't do anything about, but I've had to root out several retain cycles that Leaks never found. For finding retain cycles, I recommend using "Allocations" and running several heap shots between performing the action you suspect of 'leaking'. You then then look through the interim heap shots to find the culprit.