Guarantee a deallocation in ARC

Question

I'm currently developing a game for iOS and we have a memory leak. Our project is ARC set up. I was wondering on how to ensure memory deallocation. One of the steps I was thinking of taking was convert code of the form:

-(void)methodMethod{
    Object* o = [[Object alloc] init];
    // Some logic
}

into:

-(void)methodMethod{
    Object* o = [[Object alloc] init];
    // Some logic
    o = nil; // Explicit nil assignment
}

Is there a difference between the two? What other measures should I take to ensure a dealloc in an ARC setup?

We're using the Sparrow Framework.

Answer 1

Both methods do the same thing. Local objects are set to nil by ARC when they leave scope, so putting in a manual nil does nothing.

If you want to find a leak - you are far better off actually running it through Instruments with the Leaks tool and finding out what is being leaked, which will give you a better idea of what is going on. It's quite handy for finding retain-cycles.

Answer 2

the following is unnecessary but (at least for me) the discussion in the comments was helpful and that's why I leave it

wrap the method in an @autoreleasepool. that will make it 99% percent sure it is being deallocated

-(void)methodMethod{
    @autoreleasepool {
        Object* o = [[Object alloc] init];
        // Some logic
    }
}

Answer 3

As pointed out by Abizem, both methods lead to the same results, and require careful passes through Instruments. The results are not always easy to interpret.

In ARC, you should never see a leak - in the usual obj-C meaning -. Sometimes, iOS instruments can report a leak, but most if not all, this comes from the runtime, and I tend to regard them as beyond my control. What you can see however, is uncontrolled memory increase, which is typical of memory retention. Keeping strong pointers on objects is the obvious reason, which in my case has always been the consequence of : retain cycles in code blocks, and incorrect data structure cleanup, i.e. objects are created, then filled into arrays, dictionary, page control etc... but the later were not emptied properly during the app lifecycle.

Also image processing functions still use standard malloc/free directives embedded into internals UIGraphics lib, so in that case you explicitly need to free the memory (CGImageRelease, etc...). ARC will not help here.

hope this helps narrow down the problem, which as Abizem pointed out, should start with Instruments.

Answer 4

Both are the same.

A better solution to test your class:

- (void)testDealloc
{
    __weak CLASS *weakReference;
    @autoreleasepool {
        CLASS *reference = [[CLASS alloc] init]; // or similar instance creator.
        weakReference = reference;

        // Test your magic here.
        [...]
    }
    // At this point the everything is working fine, the weak reference must be nil.
    XCTAssertNil(weakReference);
}

This works creating an instance to the class we want to deallocate inside @autorealase, that will be released (if we are not leaking) as soon as we exit the block. weakReference will hold the reference to the instance without retaining it, that will be set to nil.