内存泄漏（ARC）

Question

In the follow up of my previous question , I concluded that I do have a memory leak. To sum up, memory starts at 9.7MB and goes up 0.1MB every 10 runs of the animation, or so it seems. I tested this to about 12MB.

Using Instruments, I run a test that consisted of:

1. Register an initial generation
2. Run the animation 10 times
3. Register another generation
4. Repeat a few times

Here's what I got:

So the memory does grow. However, inspecting these generations it seems that I'm not responsible for these leaks. For instance, inspecting the Statistics panel, listed categories seem to indicate CF, CG, NS, etc, and Malloc and __NSMallocBlock__ .

I also inspected the Call Trees and followed the branches with highest memory consumption.

Again, most memory consumption seems to be CoreGraphics related. In Allocations List, I can see more clearly what those Mallocs are. The conclusion is the same.

Providing full source code would not be practical as the application already reached a few thousands of lines. As such, I'll give an overview of what seems to be important:

- (void)animateViewDidAppear
{
    NSArray * buttons = @[self.registrationButton, self.facebookButton, self.twitterButton, self.linkedInButton];

    // [...] A bunch of GLfloat calculations here

    __block HyAnimationCollection * collection = [[HyAnimationCollection alloc] init];

    for (int it=0 ; it < [buttons count] ; ++it) {

        UIButton * button = [buttons objectAtIndex:it];

        // [...] More GLfloat stuff

        // Ease out back
        __block HyAnimation * easeOutBack = [[HyAnimation alloc] init];
        HyAnimationUpdateFunction easeOutBackUpdate = ^(id frame, BOOL done) {
            [button setFrame:[frame CGRectValue]];
        };

        [easeOutBack setDelay:it * kHyAuthenticationViewControllerAnimationDelayFactor];
        [easeOutBack setDuration:kHyAuthenticationViewControllerAnimationDuration];
        [easeOutBack setEasing:^(GLfloat t) { return [HyEasing easeOutBack:t]; }];
        [easeOutBack addRectAnimation:CGRectMake(origin.x, from, size.width, size.height)
                                   to:CGRectMake(origin.x, to, size.width, size.height)];
        [easeOutBack addUpdateFunction:easeOutBackUpdate];
        [collection addAnimation:easeOutBack];
    }

    [collection addLock:self.animationLock];
    [collection start];
}

self.animationLock is a locking mechanism so animations don't overlap, but it's pretty much self contained and I can't imagine why it would be the source of the leak. However, those blocks do get sent to HyAnimation , which in turn is added to HyAnimationCollection , and that troubles me more and that's where I have been focusing. In sum, maybe these closures might be creating a circular retain, so lets take a look. The addUpdateFunction in HyAnimation is actually very simple:

- (void)addUpdateFunction:(HyAnimationUpdateFunction)update
{
    [self.updateFunctions addObject: update];
}

As self.updateFunctions is an NSMutableArray , it retains strong references to these blocks. So if HyAnimation is not freed, neither are those blocks, which means that the initial scope in which they were created isn't either. But, HyAnimation is declared inside a method so, so far, I see no reason why it wouldn't be released.

Which is why I think it should be because of the animation itself, that is HyAnimationCollection 's [collection start]; . Here's the interesting part:

for (HyAnimation * anim in self.animations) {
    [anim start];
}

So far so good. Here's HyAnimation 's start :

- (void)start
{
    [NSTimer scheduledTimerWithTimeInterval:self.delay
                                     target:self
                                   selector:@selector(scheduleAnimationWithTimer:)
                                   userInfo:nil
                                    repeats:NO];

    // Send an udate notification
    if ([self shouldUpdateImmediatly]) {
        [self animateAt:0.0f done:NO];
    }
}

Which pretty much delays the run and delegates to scheduleAnimationWithTimer: . This method, however, sets a timer that repeats, and therefore will be around until the animation ends (and no further, I hope).

- (void)scheduleAnimationWithTimer:(NSTimer*)timer
{
    NSTimer * scheduled = [NSTimer scheduledTimerWithTimeInterval:self.frameRate
                                                           target:self
                                                         selector:@selector(animateWithTimer:)
                                                         userInfo:nil
                                                          repeats:YES];

    // Trigger immediatly
    [self setInitialDate:[NSDate date]];
    [scheduled fire];
}

Now animateWithTimer:

- (void)animateWithTimer:(NSTimer*)timer
{
    NSTimeInterval gone = [[NSDate date] timeIntervalSinceDate:self.initialDate];
    GLfloat t = gone / self.duration;
    BOOL done = gone >= self.duration;

    // Ease
    if (self.easing) {
        t = self.easing(t);
    }

    // Make sure the last position is exact. This does not mean that t does not go over 1.0f during the animation, just the end
    if (done && t > 1.0f) {
        t = 1.0f;
    }

    // Animate
    [self animateAt:t done:done];

    // Finish
    if (done) {

        // Stop the timer
        [timer invalidate];

        // Notify completion
        [self broadcastCompletion];
    }
}

And finally animateAt:done:

- (void)animateAt:(GLfloat)t done:(BOOL)done
{
    for (HyAnimationFunction anim in self.animations) {
        anim(t, done);
    }
}

That is, this last method calls the blocks I defined earlier in animateViewDidAppear .

First of all, I believe that the HyAnimationCollection and HyAnimation instances are trapped inside the blocks, and HyAnimation has strong references to those blocks. Would you agree? How can I solve this? I tried using __block to declare both variables, but it seems to have no effect, for this matter.

Anyway, I'm also having trouble relating Instrument's memory analysis with this issue, which is why this post is so long.

Thank you for bearing with me, and I apologise for the long read.

UPDATE:

It seems I was right. Following @Stephen Darlington's post on my previous question , I overrode the dealloc method in HyAnimationCollection . Contrary to his suggestion, I did not setup a break point, but instead wrote an NSLog . Never logged anything, until now.

- (void)dealloc
{
    NSLog(@"dealloced");
}

What I did was add another property to HyAnimation , shouldCleanUpOnCompletion . If true, animateWithTimer: calls this on completion:

- (void)cleanUp
{
    // Get rid of everything
    self.animations = [[NSMutableArray alloc] init];
    self.updateFunctions = [[NSMutableArray alloc] init];
    self.completionFunctions = [[NSMutableArray alloc] init];
}

I immediately saw logs on the console, so there's definitely a retain cycle. The question is, how can I solve it? Isn't __block supposed to solve this??

UPDATE 2

I just realised this is enough:

- (void)cleanUp
{
    // Get rid of everything
//    self.animations = [[NSMutableArray alloc] init];
//    self.updateFunctions = [[NSMutableArray alloc] init];
    self.completionFunctions = [[NSMutableArray alloc] init];
}

Which means that the completionFunctions are the ones creating the closure, after all. The only place I'm currently using those is in HyAnimationCollection , more specifically here:

- (BOOL)addAnimation:(HyAnimation*)animation
{
    @synchronized(self) {

        if (self.isRunning) {
            return NO;
        }

        [self.animations addObject:animation];

        __block HyAnimationCollection * me = self;

        // Self-subscribe for updates so we know when the animations end
        [animation addCompletionFunction:^(HyAnimation * anim) {

            static unsigned int complete = 0;

            // We are only interested in knowing when the animations complete, so we can release the locks
            ++complete;

            if (complete == [me.animations count]) {

                // Reset, so the animation can be run again
                complete = 0;

                @synchronized(me) {

                    // Release all locks
                    [me.locks setLocked:NO];

                    // Done
                    me.isRunning = NO;
                }
            }
        }];

        return YES;
    }
}

That is, the retain cycle must be here, right? But where? Could it be the first @synchronized block?

UPDATE

Replacing __block with __weak allover seems to have done the trick. Even without cleanUp the objects do release, however not properly. First, it releases HyAnimationCollection , then HyLockCollection and finally all HyAnimation s. HyLock is not supposed to be released because I keep it a strong reference to it in a property.

Lets take another look at HyAnimationCollection 's addAnimation:

- (BOOL)addAnimation:(HyAnimation*)animation
{
    @synchronized(self) {

        if (self.isRunning) {
            return NO;
        }

        [self.animations addObject:animation];

        // Prevent a strong circular reference
        __weak HyAnimationCollection * me = self;

        // Self-subscribe for updates so we know when the animations end
        [animation addCompletionFunction:^(HyAnimation * anim) {

            static unsigned int complete = 0;

            // We are only interested in knowing when the animations complete, so we can release the locks
            ++complete;

            if (complete == [me.animations count]) {

                // Reset, so the animation can be run again
                complete = 0;

                @synchronized(me) {

                    // Release all locks
                    [me.locks setLocked:NO];

                    // Done
                    me.isRunning = NO;
                }
            }
        }];

        return YES;
    }
}

The problem is that this closure is only called when animations finish. Because HyAnimationCollection is the first to be released, this means that when all animations finish, HyAnimationCollection has already been released, which, as you can see, causes it not to release the locks.

Now I have quite the opposite problem =) coding is so much fun <3

Answer 1

Well, the problem seems to be this:

• if you have a strong reference to self in your block inside -addAnimation: , you get a retain-cycle
• if you have a weak reference to self in your block inside -addAnimation: , self is released too early, and your completion block is pointless.

What you need is a way to break the retain-cycle at runtime:

// Version 1:
- (BOOL)addAnimation:(HyAnimation*)animation
{
    @synchronized(self) {

        if (self.isRunning) {
            return NO;
        }

        [self.animations addObject:animation];

        // Self-subscribe for updates so we know when the animations end
        [animation addCompletionFunction:^(HyAnimation * anim) {

            static unsigned int complete = 0;

            // We are only interested in knowing when the animations complete, so we can release the locks
            ++complete;

            if (complete == [self.animations count]) {

                // Reset, so the animation can be run again
                complete = 0;

                @synchronized(self) {

                    // Release all locks
                    [self.locks setLocked:NO];

                    // Break retain cycle!!
                    [self.animations removeAllObjects];

                    // IF it still doesn't work, put a breakpoint at THIS LINE, and
                    // tell me if this code here runs ever.

                    // Done
                    self.isRunning = NO;
                }
            }
        }];

        return YES;
    }
}

1. self points to an array
2. the array points to an animation
3. the animation points to a block
4. the block points to self

When one of these connections is broken, the whole cycle breaks. The easiest way to break the cycle is to destroy the array pointer (1) by calling -removeAllObjects on the array.

---

BTW, another problem with your code is the static variable in your HyAnimationCollection . This will be a problem as soon as you have more than one HyAnimationCollection object running at the same time. I would just create an instance variable unsigned int _completeCount; :

(you could also create a synthesized property instead, but I prefer an iVar in this case:

@interface HyAnimationCollection .....
{
    unsigned int _completeCount; //is automatically initialized to 0 by the objc-runtime.
}

...

)

and in the implementation file:

// Version 2:
- (BOOL)addAnimation:(HyAnimation*)animation
{
    @synchronized(self) {

        if (self.isRunning) {
            return NO;
        }

        [self.animations addObject:animation];

        // Self-subscribe for updates so we know when the animations end
        [animation addCompletionFunction:^(HyAnimation * anim) {
            @synchronized(self) {
                // We are only interested in knowing when the animations complete, so we can release the locks
                ++_completeCount;

                if (_completeCount == [self.animations count]) {

                    // Reset, so the animation can be run again
                    _completeCount = 0;

                    // Release all locks
                    [self.locks setLocked:NO];

                    // Break retain cycle!!
                    NSLog(@"Breaking retain cycle (HyAnimationCollection)");
                    [self.animations removeAllObjects];

                    // Done
                    self.isRunning = NO;
                }
            }
        }];

        return YES;
    }
}

2.: the inner @synchronized block should be wrapped around the whole block, if it is needed at all. Just putting it around the unlocking doesn't provide any thread safety. (To test it, you can also put the line assert([NSThread isMainThread]); at the beginning of that block: if it doesn't crash, it means that you can omit the whole @synchronized(self) thing. The code then becomes:) The outer @synchronized block should probably stay.

// Version 3.
- (BOOL)addAnimation:(HyAnimation*)animation
{
    @synchronized(self) {

        if (self.isRunning) {
            return NO;
        }

        [self.animations addObject:animation];

        // Self-subscribe for updates so we know when the animations end
        [animation addCompletionFunction:^(HyAnimation * anim) {
            assert([NSThread isMainThread]);
            // We are only interested in knowing when the animations complete, so we can release the locks
            ++_completeCount;

            if (_completeCount == [self.animations count]) {

                // Reset, so the animation can be run again
                _completeCount = 0;

                // Release all locks
                [self.locks setLocked:NO];

                // Break retain cycle!!
                NSLog(@"Breaking retain cycle (HyAnimationCollection)");
                [self.animations removeAllObjects];

                // Done
                self.isRunning = NO;
            }
        }];

        return YES;
    }
}

My tip: try version 3 first. if it crashes use version 2 instead. (the scheme should be DEBUG, not RELEASE during development, otherwise assert() may not work and you may get strange problems later.) hope it works...