I am trying to find leaks in my app using the leaks instrument.
When the app launches I can see 106 leaks and I am having trouble in finding them.
In the image you can see part of the list, but how can I drill down to the class or line of code that generates the leak?
Finding a leak is not that simple. You need to wear the detective cap, take out your magnifying glass from your coat and start find the trail. i.e.
For every leaked object there is a responsible library. If it is a UIKit, Foundation or anything low-level, you won't be able to pin point the location of code that is causing the leak since these libraries are in the form of binaries.
If the responsible library is the one you are writing then you can go to the code by clicking the right method in the stack trace panel on the right. One hint is that the methods listed in the stack trace panel become highlighted if there is a corresponding code available.
But, since it is not that straight forward, often your own piece of code causes some internal library to leak which is hard to debug. You need to go through some tutorials and practice material before you start. Something certainly not answerable on stackoverflow.
You can see the stack trice in right side of the screen. And after that to scroll to the class and method that create the leak. Sometimes is hard to understand why you have the leak.
Take look on my image
I have TermsViewController and I have NSMuttableAttributed string which creates memory leaks. Also if I select the row with TermsViewController.setupInfoText() it opens the code.
If you want to find the code allocating the leaked memory, switch to the call tree view using the jump bar. To find your code in the call tree view, invert the call tree view and hide the system libraries.
Double-clicking one of your functions in the call tree view will let you drill down to the line of code that allocated the leaked memory.
Read the following article for more detailed information on using Instruments to find memory leaks:
Measuring Your App's Memory Usage with Instruments
Related
In my iOS app I am running the instruments tool to see the memory allocated. In the app I call CoreData and use that to create a survey using Apple's ResearchKit. Every time I run a new one I see an increase in the amount of 'persistant bytes' increases. When the app is run, whenever it is run multiple time over and over eventually the app closes.
I can see using Fabric's Crashylitics that a Out of Memory session occurred.
What's the best way to go about finding and fixing the memory that seems to be retained?
Your screenshot is not showing any memory leaks so you should start by using the Allocations instrument, the graph of which is in your screenshot.
Start by setting an inspection range where the memory usage spikes. Click in the graph and drag to set the inspection range. You will notice that the graph color outside the inspection range changes to gray. At this point you have focus on where the memory usage spikes.
To find the place in your code that's causing the increase in memory usage, switch to the call tree view by clicking in the jump bar below the graph and choosing Call Trees. Inverting the call tree and hiding system libraries makes it much easier to find your code in the call tree. Click the Call Tree button at the bottom of the window to invert the call tree and hide system libraries.
If you find a function in the call tree that is allocating a lot of memory, you can double-click it to show the lines of code that are allocating the memory.
Another tool you can use to analyze memory growth is the Allocations instrument's generations. Run your app, pause, and click the Mark Generation button to create a generation. Repeat to create multiple generations. Choose Generations from the jump bar to see how much memory growth you have from generation to generation.
I am having problem on memory leak tracking, i did try profiling but the instrument shows firapb_decode_repeated_user_attribute as as responsible object. And while i try to track code it takes me to assembly code which is more painful. Do anybody have similar issue or have some clue to track this issue, It will be a lot for me.
Leaked Object # Address Size Responsible Library Responsible Frame Malloc 32 Bytes 1 0x600000231ba0 32 Bytes appName firapb_decode_repeated_user_attribute
The Assembly code
Yes as Larme said it was the Firebase leaking the memory.
I am still not knowing the exact cause (line of code) but disabling firebase app analytics from firebase plist solved the problem,
Even you are not using firebase app analytics with setting IS_ANALYTICS_ENABLED = NO on GoogleService-Info.plist. fire base SDK seem executing the app analytic codes by default.
Solution:- Adding FIREBASE_ANALYTICS_COLLECTION_ENABLED = NO on GoogleService-Info.plist, wipe out the leak problem.
This is only my perception and observation, this topic may need more information and expiations.
If you want to find the area of your code where the leak occurs, switch to the call tree view. The jump bar is at the top of your first screenshot. Click the Leaks item in the jump bar and choose Call Tree to switch to the call tree view.
When you're in the call tree view, selecting the Invert Call Tree and Hide System Libraries checkboxes will make it easier to find your code in the call tree view. Starting with Xcode 8.3, the checkboxes are in a popover that you open by clicking the Call Tree button at the bottom of the window.
Earlier Instruments versions have a display settings section with a Call Tree collection of checkboxes.
I have found a memory leaks through Leaks, but it only showed the address and the leaking bytes as below. I want to know how to detect the reason causing the memory leaks? Anybody know?
Open the extended detail panel (on the right).
Select one of the elements in the list and look at the extended detail panel, which shows the stack trace that caused the object to be created, as below:
Double click on it to see the code for that method.
For more about How to Use Instruments in Xcode, read the raywenderlich excellent tutorial here
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.
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.