I have an IOS app that displays images and text in a UITableView. When I scroll up and down I get this unbounded memory growth. I have used Allocations to attempt to find out where this memory growth comes from. Please see below. From what I can see, CFString takes up a huge amount of memory. It doesn't appear to be from my code(based on StackTrace of CFString) as seen in Figure 2.
Please can someone advise? I'm really stuck. My app is crashing after a few minutes of scrolling after exceeding around 2GB of memory. I would appreciate any general pointers on how to debug the origins of the memory issue. The CFString stack trace appears all grayed out and I'm not sure how to proceed to diagnose the issue.
Figure 1
I am looking at CFString and the persistent memory is huge.
Figure 2
Clicking on CFString:
Try using the Instruments app, in the Xcode utilities folder. Specifically you want the Leaks instrument. It will find leaked memory, and then help you figure out where that memory gets allocated.
Run your app for a while, then break it and examine your heap.
(It's rather complex and tricky to use. Much more than I can explain in an SO answer. I suggest digging up a WWDC video or other tutorial on using it.)
There is also a simple memory graph tool in Xcode that flags leaked blocks, but it doesn't give you as much information. (It's one of the little icons in the debug bar above the debug console. The icon is 3 little circles with lines between them.)
Related
I started looking for the memory leaks when I received memory warning.I have read some material on how to solve memory leaks but when I run Instruments things shown seem a bit abnormal to me. The call tree is empty and the extended detail panel is showing no stack trace. Also I am not able to understand the graph shown in Root Leaks(cycles & roots) I have attached the screenshots below.
screenshot: cycles & roots
Leaks
Ray Wenderlich and his team explain this sort of thing very nicely.
https://www.raywenderlich.com/2696/instruments-tutorial-for-ios-how-to-debug-memory-leaks
Time for more studying. :o)
I've developed an iOS application. There is a main screen which is displaying a google map and there are many markers, polygons etc in it.
At the beginning app was using around 120MB of memory.
- I touched settings button of my app and went to the settings page. there is no code. only segue connection in the storyboard (red line on the image)
- then I came back to the map screen (white line on the image)
You can see the memory allocation. every time when I open the map screen memory usage is increasing
What is the problem. What should I do?
The graph you have captured in Xcode is a decent overview of your memory consumption, but I'm afraid you are going to have to use more specific tools to diagnose this leak: Instruments comes shipped with Xcode and will help you track memory leaks; you will have to research (at least) the Leaks and Allocations instruments to figure out why your View Controller isn't being released.
While it is impossible to diagnose without seeing your code, that graph heavily suggests that your map view controller is not being released (hence the steady growth each time you create a new one)
To hazard a guess, I'd imagine you are creating a new mapView in viewDidAppear rather than viewDidLoad
I'm doing a screenshot of the allocations in my project. I've simulated a memory warning at 50 seconds, but the allocations never go back down. Maybe I don't understand this one correctly?
I think the graph is displaying the overall bytes, ie all the memory consumed by the application during her running time
It turns out that NONE of my big objects (UIViews / Controllers) were ever being released. After diving in I'm seeing some up and down like I should be.
I'm attempting to use the Memory Leak instrument in Xcode 4 with iOS 5.1 (ARC enabled) and I am spotting memory leaks, but how the hell do I get to the line of code causing the leak? I've read a few tutorials on this but it seems to be an older version of the instrumentation tool because when I click on the extended detail tab and double click on items in the backtrace I'm presented only with useless assembly code. Also none of the items on the stacktrace are any of the classes that I've written. Am I missing something?
If your code leaks memory, you will see your relevant methods in the details tab, right where you are looking. They are displayed in black as opposed to methods in the APIs which are gray. You can't look into API Methods of course, hence the assembly code. If there is really something wrong in your code, set the slider on the bottom of the tab on the rightmost position and you should see the concerned methods.
If still none of them are in your code, you probably just don't leak anything. (There are actually not many scenarios in which ARC-Code can leak memory. Retain cycles are probably the most common one) I stumbles over one or two cases in which an API was 'leaking' memory. There is really nothing you can do about it and most likely, it's just a false positive anyway rather than a real leak. If you are only 'leaking' a few bytes, I wouldn't worry about it.
I am using instruments to pindown on what is consuming more memory. I always get the Living bytes and overall bytes to be same. I believe not much deallocation has happened in my code. And this is a bad sign.
When I go and find the responsible caller and track down what it is, I could not find it. The responsible callers are _dydldstart and NSStringFromClass.
Is this behaviour normal ? How can check the exact responsible caller?
The cause of the Living Bytes and Overall Bytes columns being the same is most likely that Instruments is tracking only active allocations. If you want Instruments to track everything, click the Info button next to the Allocations instrument in the instrument list and deselect the Only track active allocations checkbox.
Opening the extended detail view shows the call stack for your memory allocations, which will make it easier to find the exact responsible caller. Choose View > Extended Detail to open the extended detail view.
The call tree view can also help you determine where you are allocating memory in your code. Use the jump bar to switch to the call tree view.
"I always get the Living bytes and overall bytes to be same".
I had this problem only because I was setting up NSZombieEnabled as environment variables when I was testing my App in Instruments. After disabling that variable, the problem had gone.
NSZombieEnabled I think does not let any variables to be released.
I am not sure if removing NSZombieEnabled solved the probelm.
I was actually using Allocations in two different ways. Only when used with Leaks Tool, I had the problem.
Another question of Mine is an answer to this question:
Ambiguities in using Instruments for iOS Development