I used to verify that some of my variables had the expected retain count using [myVar retainCount] under the debugger, especially for var that did not have a custom dealloc.
How do you do this in ARC mode? How do you ensure that there are no memory leaks?
Note: I understand that ARC should handle this for me, but life is far from being perfect, and in real life you have objects that are sometimes allocated by third party libraries (using retain?) and never deallocated.
Image that I do this:
MyObj *myObj=[[MyObj alloc] init];
then I call
[somethingElse doSomethingWithMyObj:myObj];
and later, I do
myObj=NULL;
If my program is working fine, my expectation is that myObj is being destroyed, but it appears not to be the case...
So how can I track this, especially if somethingElse is not managed by me?
Now, about the tools: it seems extremely hard to run memory tools on my mac (with 5 Meg) without rebooting the mac and starting from scratch. This is really annoying! Instruments keep crashing even before the program has started, so is there an alterante solution?
You can use
CFGetRetainCount
with Objective-C objects, even under ARC:This is not particularly useful for debugging, though, for reasons amply described elsewhere. If you need to understand where an object is being retained and released, check out this answer for help using the Allocations instrument.
The only case I've found where examining the retain count is actually useful is in a
dealloc
method, when something retains and autoreleases the object being deallocated. This will cause a crash later when the autorelease pool is drained. You can pinpoint the cause of this by checking the retain count before and after each message. In this way I discovered that theobservationInfo
method (which is itself usually only useful for debugging) retains and autoreleasesself
. However, even this sort of problem can usually be solved without examining the retain count, simply by wrapping the entire body ofdealloc
in an@autoreleasepool
block.However, the retain count can be used to learn about the implementation of some classes. (Only do this for entertainment or curiosity! Never rely on undocumented implementation details in production code!)
For example, try this immediately inside the
@autoreleasepool
inmain
:So
NSNumber
likely caches (or at least reuses) some instances. But not others:You can even discover that
NSNumber
returns a singleton if youalloc
but don't initialize:(Note that you can also learn many details about
NSNumber
by looking at the Core Foundation source code, which is available at http://opensource.apple.com. But who knows what you might find if you look at the retain count of objects that aren't toll-free-bridged with objects in Core Foundation?)You don't. ARC handles the memory management for you and does not allow you to call retainCount and even if you could see it, the number it returns is meaningless for you. If you want to you should be doing memory profiling in Instruments with the Leaks and Allocations instruments. That is the best way to look and see how your application is allocating memory and catch any improper use of memory there.
Get the object's
retainCount
?You can just make a breakpoint and input the command below to get the object's
retainCount
You don't. Apple say you don't need to as ARC will handle it for you.
Use Instruments and locate the object you want to track by searching for the class name or pointer address if you have it while in in "Objects List".
When you have located it, hit the disclosure arrow on the instance. This brings you to a history view for retains and relases.
If you expand the right side detail view you will also see the callstack for each retain/release.
You should never use retainCount for anything, with or without ARC.
When to use -retainCount?