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
Related
I'm afraid that asking this question may result in some downvotes, but after making some not satisfying research I decided to take a risk and ask more experienced people...
There are many questions here referring to some specific problems connected with the XCode Analayzer Tool. It seems to be very helpful solution. But I would like to ask you - as a beginner in iOS world - what kind of memory management stuff cannot be noticed by this tool.
In other words, are there any common memory management aspects, about which the iOS beginners should think "Oh, be careful with that, because in this case XCode Analyzer may not warn you about your mistake"...
For instance, I've found here Why cannot XCode static analyzer detect un-released retained properties? that:
(...)the analyzer can't reliably detect retain/release issues across
method/library boundaries(...)
It sounds like a good hint to consider, but maybe you know about some other common issues...
The analyzer is very good at finding the routine leaks that plague new programmers writing non-ARC code (failures to call release, returning objects of the wrong retain count, etc.).
In my experience, there are a couple of types of memory issues it does not find:
It cannot generally identify strong reference cycles (a.k.a. retain cycles). For example, you add a repeating NSTimer to a view controller, unaware that the timer maintains a strong reference to the view controller, and if you don't invalidate the timer (or do it in the wrong place, such as the dealloc method), neither the view controller nor the timer will get released.
It cannot find circular logic errors. For example, if you have some circular references where view controller A presents view controller B, which in turn presents a new copy of A (rather than dismissing/popping to get back to A).
It cannot find many non-reference counting memory issues. While it's getting better in dealing with Core Foundation functions, if you have code that is doing manual memory allocations (such as via malloc and free), the static analyzer may be of limited use. The same is true whenever you're using non-reference counting code (e.g. you use SQLite sqlite3_prepare_v2 and fail to call sqlite3_finalize).
I'm sure that's not a complete list of what it doesn't find, but those are the common issues I see asked about on Stack Overflow for which the static analyzer will be of limited help. But the analyzer is still a wonderful tool (it finds issues other than memory issues, too) and for those individuals not using ARC, it's invaluable.
Having said that, while the static analyzer is an under-appreciated first line of defense, you really should use Instruments to find leaks. See Locating Memory Issues in Your App in the Instruments User Guide. That's the best way to identify leaks.
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've been asked to try and reduce memory usage in an app's code I have been given. The app runs fine in the simulator but on the device it is terminated or something, when debugging it enters a 'Paused' state and the app closes on the device.
When running instruments I discovered leaks, fixed them, however there is a large amount of allocation going on. Within a few seconds of launch the instruments allocation trace shows 1,021 KB for 'Malloc 16 Bytes'. This is essentially useless information as is, I need to see where the memory is being allocated but I can't seem to find anything useful. All i can get for a deeper inspection is that 'dyld', 'libsystem_c.dylib', 'libCGFreetype.A.dylib' etc are allocating a lot, but the responsible caller is never a recognizable method from the app source.
How can I see what methods are causing the most allocations here? I need to get this usage down! Thank you
Opening the extended detail view will show the call stack for memory allocations. Choose View > Extended Detail to open the extended detail view.
Switching to the call tree view will help you find where you are allocating memory in your code. Use the jump bar to switch to the call tree view.
1MB is no big deal. You can't do much in terms of throwing up a full view without using 1MB.
There's a good video from WWDC 2010 (http://developer.apple.com/videos/wwdc/2010/) that covers using instruments to analyze memory use. Title is Advanced Memory Analysis with Instruments. There may be an updated video from 2011.
How to detect memory leak. I mean is there any tool/utility available or any piece of code (i.e. overloading of operator new and delete) or just i need to check the new and delete in the code??
If there any tool/utility is there please tell me. and if code is there then what is the code can any one explain?
Tools that might help you:
Linux: valgrind
Win32: MemoryValidator
You have to check every bit of memory that gets allocated (new, malloc, ...) if it get's freed using the appropriate function (delete, free, ...).
Use e.g. boost:shared_ptr instead of naked pointers.
Analyze your application with one of these: http://en.wikipedia.org/wiki/Memory_debugger
One way is to insert file name and line number strings (via pointer) of the module allocating memory into the allocated block of data. The file and line number is handled by using the C++ standard "FILE" and "LINE" macros. When the memory is de-allocated, that information is removed.
One of our systems has this feature and we call it a "memory hog report". So anytime from our CLI we can print out all the allocated memory along with a big list of information of who has allocated memory. This list is sorted by which code module has the most memory allocated. Many times we'll monitor memory usage this way over time, and eventually the memory hog (leak) will bubble up to the top of the list.
valgrind is a very powerful tool that you can use to detect memory leaks. Once installed, you can run
valgrind --leak-check=full path/to/program arguments...
and valgrind will run the program, finding leaks and reporting them to you.
I can also recommend UMDH: http://support.microsoft.com/kb/268343
Your best solution is probably to use valgrind, which is one of the better tools.
If you are running in OS X with Xcode, you can use the Leaks tool. If you click Run with performance tool and select Leaks, it will show allocated and leaked memory.
Something to remember though. Most of the tools listed only describe tools that catch memory leaks as they occur. So if you have some code that leaks memory but is rarely called (or rarely enough that you don't encounter it when testing for memory leaks), then you could miss it. If you want something that actually runs through your code, you'll need a static analyzer. The only one I know of is the Clang Static Analyzer, but it is for C and Obj-C (I don't know if it supports C++).
Let's put Heisenberg aside for a brief moment.
How would I go about to, from within my own process, monitor how much memory this process is using?
(I might have under-specified the question on purpose, dreaming of creative answers...)
Quassnoi is correct - but it also might be worth checking our this question:
How to determine CPU and memory consumption from inside a process which includes code examples
Use GetProcessMemoryInfo()
WorkingSetSize in PROCESS_MEMORY_COUNTERS_EX seems to be what you want.