I followed this video tutorial for detecting memory leaks using Instruments with Xcode 4.3.2.
As you can see from the video, the creator gets a lot of useful feedback on the type of object that was leaked etc.
When I run instruments, I detect a few memory leaks but don't get much useful feedback on them:
What does it mean "Root Leaks"? Why is there no more useful information like in the screen above?
Is this something I can fix?
I'm using ARC within my app - does that effect Instruments finding memory leaks in any way?
A root leak can be one of two things. It can be a single memory leak, or it can be the start of a leak cycle. A leak cycle occurs when you lose a reference to a group of objects. A memory leak leaks one object while a leak cycle leaks a group of objects.
Your code may not have any leak cycles, which would explain why your Cycles and Roots section shows less information than the tutorial. Choosing Call Tree instead of Cycles and Roots from the jump bar can help you find the areas of your code that are leaking memory.
Related
In the Memory Leaks tool in XCode 7 what do those crosses in the timeline represent (and the grey shape with the minus)? I could not find this in the documentation and they appear regularly on the timeline.
I get a long lists of leaked object (this is a big project developed in the last years). Should this list be always empty, or it's normal to get some leaks in a running app, or does this implies that it's bad written code?
I can answer the first question. The Leaks instrument checks for memory leaks every 10 seconds initially. If the Leaks instrument finds new leaks since the last check, it shows a red symbol with an X in it (the red crosses). The gray symbol with a minus sign means the Leaks instrument has found memory leaks, but no new leaks since the last check.
The goal is to get the Leaks instrument to show a green symbol with a checkmark. That means no leaks were found.
Summary
Green: no leaks
Gray: no new leaks
Red: new leaks
Just to have an idea: should this list be always empty, or it's normal
to get some leaks in a running app, or does this implies that it's bad
written code
No, it is not a normal thing and surely this is an ugly code with these many leaks.
If you are dealing with this application now, you should try to reduce to ZERO leaks, or minimise to an acceptable state(here I mean if some leaks are from some 3rd party libraries).
Even I worked on a project that is in production from a decade with 2K classes, that doesn't have any leaks, but ever release we find some and remove it, otherwise the client will not accept the code.
I am playing around with Instruments. And I just recorded/profiled for memory leaks, I had very few memory leaks, but an overwhelming amount of allocations just keep going even when my app just opened. Here is a screenshot after using the app for less than 10 seconds.
And as I keep using the app it just keeps increasing and increasing.
The weirdest part is most of the allocations are coming from classes I don't know like:
Foundation
Altitude
lbdispatch.dylib
But it could be from the SBJson and the other classes I imported and added for JSon and XML.
But is this a lot of memory allocations? Is too much bad???
Yes and no, it depends on what you are doing, if you allocate for example a lot of strings, lets say you allocate 1000 strings these allocation perse are not bad, but it depends on your logic view of your application, if you really need all the strings at once and you need them to be allocated and alive through all the steps of your application, then you dont have anything to do, your application just needs alot of memory,
However on the other hand, you may find some other ways to logically structure your application, like for example you could only allocate each of the 1000 string once you need it.
A very abstract answer is, if your app requires a lot of memory and there is no way to use some techniques such as lazy loading, or caching, then you dont have any other solution
But if you can restructure your application to use lazy loading, caching, allocation pools it would bee better
Please note: that you could let iOS sdk help you, by implementing correctly the memory warning callbacks in your application, in such a way that whenever you receive a warning, you start releasing any resource that you dont currently need
Also, do you have Zombies on? Zombies default to not actually removing any allocations, so memory is never deallocated. Always test for memory leaks with Zombies off.
I'm trying to debug a mysterious app crash that happens after running the app for a few hours.
My hunch is that this may be memory related, as I've not done any memory optimization since starting to build my app.
I'm looking at my application with the "allocations" instrument and I see these numbers:
All allocations 4.70mb
Living 51072
Transitory 357280
Overall Bytes 100.23mb
Overall 408000
Which is the important number here? Does my app take 4.7 Mb of memory or 100 Mb? At which point should I be concerned about my app being killed for memory reasons? I want to avoid premature optimization :)
Since I'm using ARC and TabBarController, most of the controller related memory seems to be out of my hands, unless I find out how to create a tab and lazily init a controller when that tab is first touched.
Thank you!
I'm sure it's a memory leak, and I'm certainly no expert in memory allocation, but instruments says I have a memory leak of zero bytes...
Can someone explain what exactly that means?
The leaked object (including the responsible party that initiates it) should appear in the lower half part of the Instruments window, once you have selected the "Leaks Discovered".
Doing an "Analyze" (Command + I) in XCode will also show possible memory leaks in your code.
I am mystified by a memory leak: It says the responsible library is "AppSupport" and the Responsible Frame is "CPRecordLoadHandler". Not quite sure where to begin. I know that it's when a specific view controller loads so obviously I can narrow it down a bit but I can't find a single result in Google that explains what a CPRecordLoadHandler memory leak comes from.