Heap Allocation and Call Tree buttons on VMMAP tool Disabled - vmmap

I understand the Heap Allocations button should allow me to see call stacks, but the button is always disabled (grayed out) no matter what I try. (I used the "Launch and Trace New Process" feature to run my application, but it doesn't help.)
Thanks
Rambabu

Related

Out of Memory issue iOS

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.

This is Memory issue or not

When will i have running my app in simulator. xCode debug section shows cpu and memory section it will display some graph flow. but i don't know what is that.
My question is,
what is that cpu and memory graph
when i running my app the memory increase towards when ever i navigate to any other viewcontroller and return back same or other viewcontroller etc., it always increase the memory size.
why it occurs. Is that any problem. if yes how to fix that and why i caused.
Here below image i navigated to any other view controller. it is suddenly increase from above image memory size to below image memory size.
Well from overall memory consumption it would seem as if you are handling some images or videos or other heavy content. Many make memory leaks handling those. To test if thats a real leak, you can do so:
Go to some page A (any page), from there go to some other page B, then back to A, back to B.. repeat that and if your memory is really getting high - you have a leak.
BUT bear in mind: These graphs show you how much resources your app use from your device, you SHOULD NOT use that to find leaks. Instead go to profiler, choose memory leaks and use that. If you are using ARC and cannot find any leaks, you can use "mark heap" button in allocations instrument to find memory build ups like this: Repeat the "page A page B" cycle and every time you are in page A, press "mark heap" button. You will now see generations which each show how much memory has increased from last generation. If it always keeps increasing same amount - double clicking generation will show you all the places that you have possible leaks.
Additional info: Easiest way to profile your app is to hold left mouse on "play" button in xcode until more buttons pop-up. Choose profile. When instruments appear - choose "Leaks".
From there - you should be able to see overall statistics of your app. I will not go in detail about profiler, because all the info is already available in the net. For example: https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/Introduction/Introduction.html

How to detect the reason of memory leaks according to the address providing by Leaks?

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

How to see the whole picture in mplab ipe?

I'm using MPLABX IPE 1.95 on linux. For some reason the programmers decided to make the main window non-resizeable.
So it's impossible to see the memory view properly. If the memory view isn't open, I can't even see the bottom of the output window.
Is there any trick to make the window the right size?
Otherwise, can someone perhaps give the developers monitors that are larger than 640x480?
I hope the status isn't important
I experienced the same problem. A workaround is to right-click in the Output or Memory View window and select Undock from the context menu. From my experience, the Status is not important. It shows the progress of the configuration changes when in Advanced Mode.

Understanding responsible callers in Instruments Results for Alloc

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

Resources