Is it possible to get more meaningful information on a leaking object in instruments? At the moment Instruments will tell me the type (NSArray) and the memory address (0x123456). Normally if I was debugging with LLDB I'd do a po 0x123456 to get a bit more info on the instance of the object. Is there any equivalent in Instruments, or am I approaching this in the wrong way? Any advice would very welcome!
In the leaks, call tree you can see all the leaks you have, double clicking on any of them will show you the segment of code that is producing it, it also adds a percentage on the line it thinks its doing the leak
Also you can add NSLogs in your code and in instruments navigate to console view to see the logs
Related
Now i'm developing iPhone app but it seems happen memory leak. I found by Instruments:
I have question:
-- how to find where is code that happen memory leak about "Malloc xx bytes"?
-- I think I can't improve memory leak in Library. Example for "Foundation", "StoreKit" and so on, right?
Switch to the call tree view to find the areas of your code allocating the leaked memory. For more detailed information, see my answer to the following question:
Unable to track memory issue
Also for clearer representation of memory leaks select Allocation tool, go to File>Recording Options and tick "Discard events for freed memory".
In this way all the spikes that you will see in the chart will be actual unfreed memory
As I start working in swift, I am curious in memory mgmt. As we all know that during any object creation or assignment of data into that object it takes memory. How can we check that a particular object has released the memory. I used xcode memory report to see memory status and fluctuations.
Here is a sample of images:
How can release memory if I already set nil into the objects.
Use instruments to track the lifecycle of an object than just Xcode because it gives you the allocation details at much higher level.
Check out the answer at https://stackoverflow.com/a/14891837/5133769. Though it was explained with old instruments it still works.
Some objects are very small and it could be difficult to see in Memory profiling which one is released. This tool is helpful for finding memory leaks in an app. To check was some object released from memory or wasn't you can setup breakpoints or logs in dealloc() method for objective c and in deinit() method for swift.
Using instruments checking for leaks or allocations is the recommended way.
You can also set breakpoints or add logs to the dealloc method.
After getting numerous memory warnings in the console , I tried using the memory profile tool to understand the root cause. But I don't see any strange behavior in memory allocations.
Is there a way to know what exactly is causing the warning?
Edit:
Print screen of profiler
Thanks for any guidance
sorted By "Overall Bytes" and "Created and Still living"
and added some detail to that:
and the code detail:
There is no single reason for memory warning. First of all you should always profile on real device - never simulator.
Add a profiler gadget called "leaks" to search for memory leaks on profiler while doing profiling.
You can get memory warning depending on a device even at around 10 - 12MB used by your application. Unfortunately there is no official information from Apple how much you can safely use.
In profile check also Total Living bytes. Try optimizing your code with autoreleasepools (if you are doing lot's of object allocation in "for" loops for example.
You can also check in Profile which objects takes most space.
Without real project to play with - it will be really hard to point a problem. Depending if it's a game and how much images you're using - problem may be different.
as the title says, I have an app which works on iPad 2, but crashes on iPad 3. when running it the console gives me a low memory warning message. When the crash happens I symbolicate it, but there's really nothing that I can relate to the code, like it shows
process name, UUID, rpages, recent_max, [reason] (state)
and under those column headers just hexadecimal stuff, nothing showing method calls or lines in the project.
Any ideas? am I missing some flags in the code that allows for a better crash log?
Thanks.
If you're getting low memory warnings and fail to release enough memory to resolve the issue, your app will almost certainly crash. The thing is, I don't think that the particulars of how or why it crashed can possibly be illuminating. At that point, you're evaluating secondary symptoms. You really need to go back and figure out why you got the low memory warning in the first place and fix that problem.
As Daniel said, you can look at Technical Note 2151, but as it says:
When you see a low memory crash, rather than be concerned about what part of your code was executing at the time of termination, you should investigate your memory usage patterns and your responses to low memory warnings. Memory Allocations Help lists detailed steps on how to use the Leaks Instrument to discover memory leaks, and how to use the Allocations Instrument's Mark Heap feature to avoid abandoned memory. Memory Usage Performance Guidelines discusses the proper ways to respond to low-memory notifications as well as many tips for using memory effectively. It is also recommended that you check out the WWDC 2010 session, Advanced Memory Analysis with Instruments.
So, a couple of thoughts:
Have you looked for leaks? The Finding Leaks article walks you through how to use instruments to find your leaks.
If you turned on zombies, have you turned them off? Zombies is a great diagnostic tool, but just consumes memory.
Have you run your code through the static analyzer (shift+command+B or select "Analyze" on the "Product" menu)? Especially if using non-ARC code, this can find lots of memory issues.
Have you examined your allocations for unexplained increases without offsetting decreases with the Instrument's Allocations tool. Using that, you can run the program, look at the consumption of memory on the graph and see if you see any increases that aren't offset at some point by the corresponding decreases. And if so, highlight those increases in the graph:
For example, when running the Allocations tool, hold down the option key and then click-and-drag with your mouse to highlight a portion of the timeline, to identify what you want to inspect. You probably want to focus on one of your spikes in allocations. For example, I found a bump in my allocations and highlighted it as such (this was a ludicrously simple example where I create a huge array in viewDidLoad, but hopefully it give you the idea):
Note, I find it useful to show the call tree in the lower panel, it's often useful to select "Hide System Libraries", to focus on your code (and "Invert Call Tree", too). And if you double click on the method name in Instruments (in my example, here, it would be viewDidLoad), Instruments will then show you your code that's doing the allocation:
Low memory warnings generate a different kind of log than standard crashes. Take a look at the "Understanding Low Memory Reports" section of this article to understand what happened with your application and how you can debug it using Instruments: http://developer.apple.com/library/ios/#technotes/tn2151/_index.html
I am using instruments to check my app for leaks and I am trying to learn how to read the leaks cycles data.
I am getting this graph on one of my leaks:
What is the meaning if the graph ? What does it mean "no ivar"?
The "no ivar" message is similar to looking at the call stack of a program that has its symbols stripped. If you were looking at the call stack, you would see a memory address instead of the function name. In your example Instruments is showing the addresses, +16 and +24. Instruments can't find the variable name that allocated the memory so you get the [no ivar] message.
I don't have a solution to get Instruments to provide better information. I've never been able to get Instruments to do much with leak cycles.
UPDATE
If you're trying to find where your code leaks memory, I recommend switching to the call tree view, which you can do from the jump bar. Selecting the Invert Call Tree and Hide System Libraries checkboxes make it easier to locate your code in the call tree view. The checkboxes are on the left side of the trace document window.