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.
Related
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
I just started working on a relatively complex project, and have discovered a bug. When the user logs out, the view controllers are still allocated behind the login view controller. They continue responding to rotation events, etc. I have set the controller to nil upon logout, but it's still responding, which indicates that some other object still has a pointer to it. (This project has ARC enabled.)
Pre-ARC I could likely solve this by overriding retain:
- (id) retain
{
// Break here to see who is retaining me.
return [super retain];
}
How can I use the Xcode debugging tools to select an object and list all the other objects that point to it? Is there a better approach than simply hunting through all the code?
As of Xcode 8 you can use the Debug Memory Graph:
Run your app and look at the navigator at the bottom of the screen. You should see a set of three connected circles:
Navigate to wherever so that your object is allocated in memory and then tap on this icon. It should pause your app and a graph should pop up on your Xcode screen. Now, on the left side of the screen you can see a list of objects. Find the object you want to see all the pointers to and click on it. Now they should be visible in the graph. You can expand these branches by tapping on the two arrows on the nodes at the left end of the branch. The graph should look something like this:
This saved me literally days of work. It's an extremely useful tool. I hope it helps someone else too.
The Instruments Heapshot Analysis tool was the best thing I could find for this purpose. This article provides a more complete tutorial, but the basic steps are:
Select Product -> Profile. Choose the Allocations Instrument.
On the left, press the Mark Heap button before/after significant events. In my case, this was before login, after login, and after logout.
Search through the Heapshot for the class you're looking for.
Press the disclosure triangle to see its memory address(es).
Press the arrow to the right of a memory address to see its responsible caller (it appears in the rightmost column.)
If someone else writes up a more thorough explanation, or can offer any related lldb commands, I'm happy to mark your answer as correct.
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.
In my app, I am using Core-plot library to plot Vertical bar chart. When user taps on bar it should navigate to the another View-controller. (It will be off same view-controller's instance). When i push like this only for example 12-15 times i receiving memory warning & App crashes.
Did anyone faced same issue while using Core-plot library?
Thanks
Naveen.
Check your app by memory tools in Instruments.app. Maybe you can find some memory leaks. Memory warnings appears when your project use a lot of memory. And there is no reason to think that problem is in CorePlot. (as you said you creates more than 10 view controllers. Do you release them?)