Question

For years I’ve been following a great pattern called Target-Action which goes like this:

An object calls a specified selector on a specified target object when the time comes to call. This is very useful in lots of different cases where you need a simple callback to an arbitrary method.

Here’s an example:

- (void)itemLoaded {
    [specifiedReceiver performSelector:specifiedSelector];
}

Under ARC it now turns out that doing something like this all of a sudden became dangerous.

Xcode throws a warning that goes like this:

PerformSelector may cause a leak because its selector is unknown

Of course the selector is unknown since as part of the Target-Action design pattern you can specify whatever selector you want in order to get a call when something interesting happens.

What bugs me most about this warning is that it says there can be a potential memory leak. From my understanding ARC doesn’t bend the memory management rules but instead simply automates the insertion of retain/release/autorelease messages at the right locations.

Another thing to note here: -performSelector: does have an id return value. ARC analyzes method signatures to figure out through application of naming conventions if the method returns a +1 retain count object or not. In this case ARC doesn’t know if the selector is a -newFooBar factory or simply calling an unsuspicious worker method (which is almost always the case with Target-Action anyways). Actually ARC should have recognized that I don’t expect a return value, and therefore forget about any potential +1 retain counted return value. Looking at it from that point of view I can see where ARC is coming from, but still there is too much uncertainty about what this really means in practice.

Does that now mean under ARC something can go wrong which would never happen without ARC? I don’t see how this could produce a memory leak. Can someone give examples of situations in which this is dangerous to do, and how exactly a leak is created in that case?

I really googled the hell out of the internet but didn’t find any site explaining why.

Answer 1

The problem with performSelector is that ARC doesn’t know what the selector which will performed, does. Consider the following:

id anotherObject1 = [someObject performSelector:@selector(copy)];
id anotherObject2 = [someObject performSelector:@selector(giveMeAnotherNonRetainedObject)];

Now, how can ARC know that the first returns an object with a retain count of 1 but the second returns an object which is autoreleased? (I’m just defining a method called giveMeAnotherNonRetainedObject here which returns something autoreleased). If it didn’t add in any releases then anotherObject1 would leak here.

Obviously in my example the selectors to be performed are actually known, but imagine that they were chosen at run time. ARC really could not do its job of putting in the right number of retains or releases here because it simply doesn’t know what the selector is going to do. You’re right that ARC is not bending any rules and it’s just adding in the correct memory management calls for you, but that’s precisely the thing it can’t do here.

You’re right that the fact you’re ignoring the return value means that it’s going to be OK, but in general ARC is just being picky and warning. But I guess that’s why it’s a warning and not an error.

Edit:

If you’re really sure your code is ok, you could just hide the warning like so:

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-performSelector-leaks"
[specifiedReceiver performSelector:specifiedSelector];
#pragma clang diagnostic pop