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.
Related
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.)
I am trying to see how much memory my program uses and identify leaks. I have tried looking at the memory page built into xcode and also the Allocation instrument. They get totally different result though (Both simulated on my 6s).
An outline of what I did...
I have a tableview that loads images from firebase. My test was keep pressing "reload all data" button at 3 second interval for a bit (30 seconds) and observe how the memory reflects what I did. Below are the results of the two screen shots.
What is weird is that for xcode result, I see that my memory just continues to climb higher and higher upon every refresh (Which suggests that I have a leak somewhere as the table view should discard the original data and load new ones. So I would expect highs and lows). So I went into the allocation instrument and did the same test. However, what I instead see is that the total persistent byte doesnt grow as crazy as before and remains hovering around 23.36mb with minor highs and lows (As what I might expect for reloading a table?)
Any explanations?
-- Update--
The answer here appears to contradict to what I believe is right
Xcode Memory Graph - showing increasing memory use - what exactly does it show?
Because I have tried hitting the refresh button for an hour to let the memory build up to nearly 1.5GB and I did get a memory warning. So I dont believe Xcode is showing "total bytes".
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 just started learning the instruments tool, and I'm pretty sure what I am seeing is not good. When I look at allocations, specifically the column "Live Bytes" and "Overall Bytes", I see the number continually increases as the app runs...
My app has two view controllers. A table view, and the second view controller displays detailed information about the row they selected in the table view, downloaded from the internet.
I kept clicking a row in the table view, followed by clicking the back button in the navigation bar... and LiveBytes continued to increase.
I'm guessing this means that my objects aren't being released from memory... but please correct me if I'm wrong.
MY QUESTION IS: How do I use the data in instruments/allocations to track down this memory issue? How do I find the objects not being released from memory?
I'm looking for tips on how to use these tools to clean up any memory problems my app has.
Thanks!
XCODE 4.2.1, deploying to iOS 5.0+
EDIT: I'm looking at the #living column and seeing objects like UIScrollView continuously increase... and never decrease. When I click the back button in a navigation bar, are objects automatically released from memory? When are objects released, or do I need to do it manually? Or could I be running into an issue due to using strong pointers, causing objects to not be released?
Whenever you want to observe memory usage in a cyclic pattern, there's the wonderful Heapshot analysis in the "Allocations" instrument.
Start your app and go to a default state.
In Instruments, press the "Mark Heap" button to create the "Baseline".
Do something in your app like pushing a view controller.
Return to the default state.
Press the "Mark Heap" button again to create a heapshot.
Repeat about five times from step 3.
This will result in a list of heapshots, each showing the objects that are still alive from that cycle. If your app has no leaks there will be no objects left in the middle heapshots.
The first one or two cycles might have warmed up some caches, the last two might not have cleaned up some reused resources. That's why it's usually a good idea to make four to six heapshots.
The magic in the heapshot analysis lies in the fact that the heapshots show you the leaked objects from previous cycles and remove them automatically when the objects are released later. In contrary to the "Leaks" instrument it also finds abandoned memory, not only leaks.
Most Probably you have discarded the arm64 and are running your app with armv7 only. Add both arm64 and armv7 as architectures
I think one of the best ways to solve memory issues is to use ARC.
Edit -> Refactor -> Upgrade to Objective-C ARC.
ARC will handle the majority of memory management in your app. Especially sice your app doesn't sound too complex, it might totally eliminate your problem. You still need to watch out for retain cycles and listen to memory warnings though. If you don't want to use ARC (which you should) at least run the static analyzer. Your problem might be something simple that the static analyzer can show you how to fix.
Edit:
You mentioned scroll views- this might be your problem: Memory leak every time UIScrollView is released
The profile tool has an instrument called 'Leaks'. It is similar to the 'Allocations' instrument but it shows you the object that was not released. May be you can use the 'Leaks' tool to find what is the object that was retained and release these object.
While profiling my iOS app I perform a simple task multiple times where I push and pop a view from the stack, and then take a heapshot. The same code is executed each time and the pushed view just contains some images which get removed as soon as the view gets popped.
Now because the persistent count is 0 for almost half of the heapshots, would it be safe to assume there is no abandoned memory?
I've heard that the rows with a persistent count greater than zero could be because of some internal caching.
I am using Xcode 4.2.1 and the app is using ARC.
Edit:
Thanks to Kendall Helmstetter Gelner I've managed to debug this problem further. I probably shouldn't have been using the simulator for debugging this. I've now run it on the device and it now looks like there is one object which isn't getting released:
After looking through the extended detail view I think I've just about found the cause of the problem.
It's hard to say from just that screenshot what might be cached or not - UIImage will cache things, possibly some other system elements too. It looks like you might be running that in the simulator, have you tried heapshot on a device?
You could also select "Hide System Libraries" to the side and get a better idea how much of your own code is involved.