I could use some help interpreting results from the Instruments Leaks tool. This is for an iPhone app that I am writing. This is using XCode 4.2 and Instruments 4.2, if it makes a difference.
After running the tool, I get a list of leaked objects. When I examine the details of one these objects, it shows what I assume to be a history of what happened to the object. For example, it shows a sequence of: malloc, retain, release, retain, release, release. It also shows a resulting reference count of 0. See the picture for a screenshot.
So my question is: why does Leaks think this is memory leak, and what do I need to do to fix that?
Check the -dealloc method for your Waypoint and make sure it is calling [super dealloc].
Related
I'm having a leak which is very hard to detect;
Can valgrind tell me which is the last call where address was accessible? and what were the values of the variables? I use Clion, can it just break when it happens?
There is no "instantaneous" detection of leaks functionality in valgrind/memcheck
that reports a leak exactly at the time the last pointer to a block is lost.
There was an experimental tool that tried to do that, but it was never considered for integration in valgrind, due to various difficulties to make this work properly.
If your leak is easy to reproduce, you can run your application under valgrind +
gdb/vgdb. You can then add breaks at various points in your program, and then
use monitor commands such as "leak_check" or "who_points_at" to check if the leak already happened. By refining the locations where to put a break, this might help to find when the last pointer to a block is lost.
See e.g. https://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands for more info.
I'm using Xcode's Instruments to find out if there's any leaks in my App. But I find the graph a little confusing. The app gets a cross when doing a certain job, but after that it gets minus signs only.
The reference count seems to get zero finally. I'm not very sure about the reading.
The official documentation is a bit outdated.
There's no explanation in the more recent Leaks instrument documentation about the snapshot icons.
By profiling code that leaks, here is a meaning for the leak indicators:
Green check (tick): No leak occurred in the snapshot interval (and no prior leaks exist).
Red x (cross): One or more leaks occurred in the snapshot interval.
Grey dash (minus): No new leak occurred in the current snapshot interval, but a leak from a prior snapshot still remains.
If leaked object from the earlier snapshot was deallocated, you would have seen a green check instead of a grey dash.
You can submit a documentation bug report to Apple requesting that an explanation be added to the documentation.
That's the evolution (or Delta) of the instance Reference Counter(ARC is applicable to Swift and Objective-C).
+1 is when an object is referred to (aka a variable points to that object), -1 is when that variable is set to nil.
The column immediately right of this one shows you the actual ref count for that object. When it reaches 0, the object is actually marked for release.
As a test to ensure that scenes are being dealloc'd i've been adding the:
-(void)dealloc{
NSLog(#"scenename Dealloc);
}
I've noticed that sometimes this method isn't called, i had previous issues with retain cycles which i believe i fixed, the main issue is that surely if it gets called sometimes it should be called every time?
I've also heard that using the nslog in this method in the scene causes its to be overwritten and therefore not called correctly, resulting in the scene not being dealloc'd, is this true? Could this be the problem causing the game to crash at present? I do see memory fluctuations (up and down) even with these log messages in place.
If you want to see exactly what objects exist within your game at different points you can use the Allocations instrument. You can find it under XCode > Open Developer Tool > Instruments
arrange the list by name, and look for the name of your project. You should see how many of your different game objects exist in memory there.
As has been previously suggested by the people above i had a memory leak and this was resolved via debugging and instruments.
When I create a brand new Cocoa (Mac OS X) application using XCode 4.5, turning off "document based" options, and turning on "Automatic reference counting", build, without changing anything, and run using the Profiler using the "Leaks" template, I see 19.76 megs of transitory memory usage, and 2.23 megabytes in "live bytes", including 3132 CFStrings, 1371 CFBasicHash, and a few hundred odd mallocs(), including 192 kb still allocated by CoreGraphics even when the program has terminated. I see all this in the "Allocations" timeline, but no output in the "Leaks" timeline. I find this disparity confusing.
I would like to know, for example, with a simple Cocoa base reference application, if possible, and if not, then I would like to know what the reference technique is to know which leaks are mine, and which are expected.
Note that with a Foundation-framework linked command line tool, the number of "out of the box leaks" is much simpler, only about 18 mallocs(), totalling 1.06 kb, so it seems that AppKit (Cocoa) is the origin of most of the default "live objects still on the heap at the end of the program, that are somehow, not leaks".
Is there some way to make a simple non-leaking Cocoa base reference application or does the framework itself leak so much (perhaps intentionally) that in fact, this is impossible?
Yes, I am aware of static analysis. Yes, I am aware of garbage collection. If someone wants to not use garbage collection, but only ARC, and wants to really see at runtime what has leaked, can that person do so, without having to ignore 14799 or so leaks in the foundation and frameworks?
Update: Source #1 of my own confusion is, as suggested, that I'm looking at the wrong timeline... However, in my own defense (or to explain my confusion), I have always considered any object which is still allocated on the heap at the end of program execution as a leak, a rule which is commonly observed in the Pascal (Delphi) and C++ world, and indeed on most non-garbage-collected languages on Linux and Windows. Maybe that's not a "leak" in the Objective-C world at all? Is a "living item" in the memory timeline still "active on the heap", and how is that different from a leak? The fact that my AppController is never told to "dealloc" was surprising to me too, but is "to be expected", I'm told.
Those look like objects that are "Created and still living." These are NOT leaks, but simply objects that have not finished their life cycle. Since the application is still running, there will always be a set of objects that are still living, but still have pointers to them.
A leak is an object that still lives, but has no pointers to it. Without a pointer, you cannot return that portion of memory to the OS.
To see actual leaks, look at the Leaks timeline in the upper portion of Instruments. When a leak occurs, you will see a red bar in this timeline. Set the inspection range around this bar to view details about the leak below
I don't understand the output from the "Leaks" performance tool in XCode. How can I interpret this output?
The Leaks Instrument looks for blocks of memory that are not referenced from the application code.
The Table View shows the addresses of the block found in such condition.
Yes, Instruments it's not simple to use, there are many leaks apparently from the OS and/or the system libraries, the details often show over-freed blocks (?!).
Life is complex :)
Leaks is only marginally useful. A much bigger problem you will have is references which are still retained that you think have been released. For that, use the Object Allocation tool with "created and still living" checked.
If you see memory use increase over time, highlight a region and see what objects are allocated in your own code that you were not expecting.
Leaks is covered in a wonderful video of Lecture 10 of Stanford's CS 193P (Cocoa/iPhone Application Programming).
http://www.stanford.edu/class/cs193p/cgi-bin/index.php