performSelector may cause a leak because its selector is unknown

Question

I m getting the following warning by the ARC compiler    performSelector may cause a leak because its selector is unknown     Here s what I m doing     controller performSelector NSSelectorFromString   someMethod       Why do I get this warning  I understand the compiler can t check if the selector exists or not  but why would that cause a leak   And how can I change my code so that I don t get this warning anymore

User · Answer

This code doesn t involve compiler flags or direct runtime calls   SEL selector    selector zeroArgumentMethod   NSMethodSignature  methodSig     self class  instanceMethodSignatureForSelector selector   NSInvocation  invocation    NSInvocation invocationWithMethodSignature methodSig    invocation setSelector selector    invocation setTarget self    invocation invoke     NSInvocation allows multiple arguments to be set so unlike performSelector this will work on any method

User · Answer

My guess about this is this  since the selector is unknown to the compiler  ARC cannot enforce proper memory management   In fact  there are times when memory management is tied to the name of the method by a specific convention  Specifically  I am thinking of convenience constructors versus make methods  the former return by convention an autoreleased object  the latter a retained object  The convention is based on the names of the selector  so if the compiler does not know the selector  then it cannot enforce the proper memory management rule   If this is correct  I think that you can safely use your code  provided you make sure that everything is ok as to memory management  e g   that your methods do not return objects that they allocate

User · Answer

For posterity s sake  I ve decided to throw my hat into the ring     Recently I ve been seeing more and more restructuring away from the target selector paradigm  in favor of things such as protocols  blocks  etc  However  there is one drop-in replacement for performSelector that I ve used a few times now    NSApp sendAction  NSSelectorFromString   someMethod   to   controller from  nil     These seem to be a clean  ARC-safe  and nearly identical replacement for performSelector without having to much about with objc msgSend     Though  I have no idea if there is an analog available on iOS

User · Answer

c-road provides the right link with problem description here  Below you can see my example  when performSelector causes a memory leak    interface Dummy   NSObject  lt NSCopying gt   end   implementation Dummy  -  id copyWithZone  NSZone   zone     return   Dummy alloc  init      -  id clone     return   Dummy alloc  init       end  void CopyDummy Dummy  dummy        unused Dummy  dummyClone    dummy copy      void CloneDummy Dummy  dummy        unused Dummy  dummyClone    dummy clone      void CopyDummyWithLeak Dummy  dummy  SEL copySelector        unused Dummy  dummyClone    dummy performSelector copySelector      void CloneDummyWithoutLeak Dummy  dummy  SEL cloneSelector        unused Dummy  dummyClone    dummy performSelector cloneSelector      int main int argc  const char   argv         autoreleasepool       Dummy  dummy     Dummy alloc  init       for         autoreleasepool           CopyDummy dummy           CloneDummy dummy           CloneDummyWithoutLeak dummy   selector clone          CopyDummyWithLeak dummy   selector copy           NSThread sleepForTimeInterval 1                 return 0      The only method  which causes memory leak in my example is CopyDummyWithLeak  The reason is that ARC doesn t know  that copySelector returns retained object   If you ll run Memory Leak Tool you can see the following picture      and there are no memory leaks in any other case

User · Answer

In the LLVM 3 0 compiler in Xcode 4 2 you can suppress the warning as follows    pragma clang diagnostic push  pragma clang diagnostic ignored  -Warc-performSelector-leaks       self ticketTarget performSelector  self ticketAction withObject  self    pragma clang diagnostic pop   If you re getting the error in several places  and want to use the C macro system to hide the pragmas  you can define a macro to make it easier to suppress the warning    define SuppressPerformSelectorLeakWarning Stuff        do              Pragma  clang diagnostic push              Pragma  clang diagnostic ignored   -Warc-performSelector-leaks               Stuff             Pragma  clang diagnostic pop           while  0    You can use the macro like this   SuppressPerformSelectorLeakWarning        target performSelector  action withObject self       If you need the result of the performed message  you can do this   id result  SuppressPerformSelectorLeakWarning      result     target performSelector  action withObject self

User · Answer

Instead of using the block approach  which gave me some problems       IMP imp     controller methodForSelector selector       void   func  id  SEL     void   imp    I will use NSInvocation  like this       - void  sendSelectorToDelegate  SEL  selector withSender  UIButton   button       if   delegate respondsToSelector selector             NSMethodSignature   methodSignature     delegate class                                      instanceMethodSignatureForSelector selector       NSInvocation   delegateInvocation    NSInvocation                                    invocationWithMethodSignature methodSignature          delegateInvocation setSelector selector        delegateInvocation setTarget delegate           remember the first two parameter are cmd and self      delegateInvocation setArgument  amp button atIndex 2        delegateInvocation invoke

User · Answer

Here is an updated macro based on the answer given above  This one should allow you to wrap your code even with a return statement    define SUPPRESS PERFORM SELECTOR LEAK WARNING code                                Pragma  clang diagnostic push                                                 Pragma  clang diagnostic ignored   -Warc-performSelector-leaks               code                                                                           Pragma  clang diagnostic pop                                               SUPPRESS PERFORM SELECTOR LEAK WARNING      return   target performSelector  action withObject self

User · Answer

Because you are using ARC you must be using iOS 4 0 or later   This means you could use blocks   If instead of remembering the selector to perform you instead took a block  ARC would be able to better track what is actually going on and you wouldn t have to run the risk of accidentally introducing a memory leak

User · Answer

Strange but true  if acceptable  i e  result is void and you don t mind letting the runloop cycle once   add a delay  even if this is zero     controller performSelector NSSelectorFromString   someMethod       withObject nil     afterDelay 0     This removes the warning  presumably because it reassures the compiler that no object can be returned and somehow mismanaged

User · Answer

You could also use a protocol here  So  create a protocol like so    protocol MyProtocol - void doSomethingWithObject  id object   end   In your class that needs to call your selector  you then have a  property    interface MyObject      property  strong  id lt MyProtocol gt  source   end   When you need to call  selector doSomethingWithObject   in an instance of MyObject  do this    self source doSomethingWithObject object

User · Answer

In your project Build Settings  under Other Warning Flags  WARNING CFLAGS   add -Wno-arc-performSelector-leaks  Now just make sure that the selector you are calling does not cause your object to be retained or copied

User · Answer

To make Scott Thompson s macro more generic      String expander  define MY STRX X   X  define MY STR X  MY STRX X    define MYSilenceWarning FLAG  MACRO     Pragma  clang diagnostic push      Pragma MY STR clang diagnostic ignored MY STR FLAG      MACRO    Pragma  clang diagnostic pop     Then use it like this   MYSilenceWarning -Warc-performSelector-leaks    target performSelector  action withObject self

User · Answer

Matt Galloway s answer on this thread explains the why      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    It seems that it is generally safe to suppress the warning if you are ignoring the return value   I m not sure what the best practice is if you really need to get a retained object from performSelector -- other than  don t do that

User · Answer

If you don t need to pass any arguments an easy workaround is to use valueForKeyPath   This is even possible on a Class object   NSString  colorName     brightPinkColor   id uicolor    UIColor class   if   uicolor respondsToSelector NSSelectorFromString colorName         UIColor  brightPink    uicolor valueForKeyPath colorName

User · Answer

As a workaround until the compiler allows overriding the warning  you can use the runtime  objc msgSend  controller  NSSelectorFromString   someMethod      instead of     controller performSelector NSSelectorFromString   someMethod      You ll have to  import  lt objc message h gt

User · Answer

To ignore the error only in the file with the perform selector  add a  pragma as follows    pragma clang diagnostic ignored  -Warc-performSelector-leaks    This would ignore the warning on this line  but still allow it throughout the rest of your project

User · Answer

Well  lots of answers here  but since this is a little different  combining a few answers I thought I d put it in  I m using an NSObject category which checks to make sure the selector returns void  and also suppresses the compiler warning    import  lt Foundation Foundation h gt   import  lt objc runtime h gt   import  Debug h     not given  just an assert   interface NSObject  Extras      Enforce the rule that the selector used must return void  -  void  performVoidReturnSelector  SEL aSelector withObject  id object  -  void  performVoidReturnSelector  SEL aSelector    end   implementation NSObject  Extras      Apparently the reason the regular performSelect gives a compile time warning is that the system doesn t know the return type  I m going to  a  make sure that the return type is void  and  b  disable this warning    See http   stackoverflow com questions 7017281 performselector-may-cause-a-leak-because-its-selector-is-unknown  -  void  checkSelector  SEL aSelector          See http   stackoverflow com questions 14602854 objective-c-is-there-a-way-to-check-a-selector-return-value     Method m   class getInstanceMethod  self class   aSelector       char type 128       method getReturnType m  type  sizeof type         NSString  message     NSString alloc  initWithFormat   NSObject Extras performVoidReturnSelector        selector  type   s     self class   NSStringFromSelector aSelector   type       NSLog        message        if  type 0      v             message     NSString alloc  initWithFormat      was not void   message            Debug assertTrue FALSE withMessage message            -  void  performVoidReturnSelector  SEL aSelector withObject  id object        self checkSelector aSelector     pragma clang diagnostic push  pragma clang diagnostic ignored  -Warc-performSelector-leaks         Since the selector  aSelector  is returning void  it doesn t make sense to try to obtain the return result of performSelector  In fact  if we do  it crashes the app       self performSelector  aSelector withObject  object    pragma clang diagnostic pop        -  void  performVoidReturnSelector  SEL aSelector        self checkSelector aSelector     pragma clang diagnostic push  pragma clang diagnostic ignored  -Warc-performSelector-leaks       self performSelector  aSelector    pragma clang diagnostic pop     end

User · Answer

Do not suppress warnings  There are no less than 12 alternative solutions to tinkering with the compiler  While you are being clever at the time the first implementation  few engineer on Earth can follow your footsteps  and this code will eventually break  Safe Routes  All these solutions will work  with some degree of of variation from your original intent  Assume that param can be nil if you so desire  Safe route  same conceptual behavior     GREAT   controller performSelectorOnMainThread selector withObject anArgument waitUntilDone YES     controller performSelectorOnMainThread selector withObject anArgument waitUntilDone YES modes      bridge NSString   kCFRunLoopDefaultMode       controller performSelector selector onThread  NSThread mainThread  withObject anArgument waitUntilDone YES     controller performSelector selector onThread  NSThread mainThread  withObject anArgument waitUntilDone YES modes      bridge NSString   kCFRunLoopDefaultMode     Safe route  slightly different behavior   See this response  Use any thread in lieu of  NSThread mainThread      GOOD   controller performSelector selector withObject anArgument afterDelay 0     controller performSelector selector withObject anArgument afterDelay 0 inModes      bridge NSString   kCFRunLoopDefaultMode       controller performSelectorOnMainThread selector withObject anArgument waitUntilDone NO     controller performSelectorOnMainThread selector withObject anArgument waitUntilDone NO     controller performSelectorOnMainThread selector withObject anArgument waitUntilDone NO modes      bridge NSString   kCFRunLoopDefaultMode       controller performSelectorInBackground selector withObject anArgument      controller performSelector selector onThread  NSThread mainThread  withObject anArgument waitUntilDone NO     controller performSelector selector onThread  NSThread mainThread  withObject anArgument waitUntilDone NO modes      bridge NSString   kCFRunLoopDefaultMode      Dangerous Routes Requires some kind of compiler silencing  which is bound to break  Note that at present time  it did break in Swift     AT YOUR OWN RISK   controller performSelector selector     controller performSelector selector withObject anArgument     controller performSelector selector withObject anArgument withObject nil

User · Answer

Solution  The compiler is warning about this for a reason  It s very rare that this warning should simply be ignored  and it s easy to work around  Here s how   if    controller    return    SEL selector   NSSelectorFromString   someMethod    IMP imp     controller methodForSelector selector   void   func  id  SEL     void   imp  func  controller  selector     Or more tersely  though hard to read  amp  without the guard    SEL selector   NSSelectorFromString   someMethod      void     id  SEL    controller methodForSelector selector    controller  selector     Explanation  What s going on here is you re asking the controller for the C function pointer for the method corresponding to the controller  All NSObjects respond to methodForSelector   but you can also use class getMethodImplementation in the Objective-C runtime  useful if you only have a protocol reference  like id lt SomeProto gt    These function pointers are called IMPs  and are simple typedefed function pointers  id   IMP  id  SEL       1   This may be close to the actual method signature of the method  but will not always match exactly   Once you have the IMP  you need to cast it to a function pointer that includes all of the details that ARC needs  including the two implicit hidden arguments self and  cmd of every Objective-C method call   This is handled in the third line  the  void    on the right hand side simply tells the compiler that you know what you re doing and not to generate a warning since the pointer types don t match    Finally  you call the function pointer2   Complex Example  When the selector takes arguments or returns a value  you ll have to change things a bit   SEL selector   NSSelectorFromString   processRegion ofView     IMP imp     controller methodForSelector selector   CGRect   func  id  SEL  CGRect  UIView       void   imp  CGRect result    controller     func  controller  selector  someRect  someView    CGRectZero    Reasoning for Warning  The reason for this warning is that with ARC  the runtime needs to know what to do with the result of the method you re calling  The result could be anything  void  int  char  NSString    id  etc  ARC normally gets this information from the header of the object type you re working with 3  There are really only 4 things that ARC would consider for the return value 4   Ignore non-object types  void  int  etc  Retain object value  then release when it is no longer used  standard assumption  Release new object values when no longer used  methods in the init  copy family or attributed with ns returns retained  Do nothing  amp  assume returned object value will be valid in local scope  until inner most release pool is drained  attributed with ns returns autoreleased    The call to methodForSelector  assumes that the return value of the method it s calling is an object  but does not retain release it  So you could end up creating a leak if your object is supposed to be released as in  3 above  that is  the method you re calling returns a new object    For selectors you re trying to call that return void or other non-objects  you could enable compiler features to ignore the warning  but it may be dangerous  I ve seen Clang go through a few iterations of how it handles return values that aren t assigned to local variables  There s no reason that with ARC enabled that it can t retain and release the object value that s returned from methodForSelector  even though you don t want to use it  From the compiler s perspective  it is an object after all  That means that if the method you re calling  someMethod  is returning a non object  including void   you could end up with a garbage pointer value being retained released and crash   Additional Arguments  One consideration is that this is the same warning will occur with performSelector withObject  and you could run into similar problems with not declaring how that method consumes parameters  ARC allows for declaring consumed parameters  and if the method consumes the parameter  you ll probably eventually send a message to a zombie and crash  There are ways to work around this with bridged casting  but really it d be better to simply use the IMP and function pointer methodology above  Since consumed parameters are rarely an issue  this isn t likely to come up   Static Selectors  Interestingly  the compiler will not complain about selectors declared statically     controller performSelector  selector someMethod      The reason for this is because the compiler actually is able to record all of the information about the selector and the object during compilation  It doesn t need to make any assumptions about anything   I checked this a year a so ago by looking at the source  but don t have a reference right now    Suppression  In trying to think of a situation where suppression of this warning would be necessary and good code design  I m coming up blank  Someone please share if they have had an experience where silencing this warning was necessary  and the above doesn t handle things properly    More  It s possible to build up an NSMethodInvocation to handle this as well  but doing so requires a lot more typing and is also slower  so there s little reason to do it   History  When the performSelector  family of methods was first added to Objective-C  ARC did not exist  While creating ARC  Apple decided that a warning should be generated for these methods as a way of guiding developers toward using other means to explicitly define how memory should be handled when sending arbitrary messages via a named selector  In Objective-C  developers are able to do this by using C style casts on raw function pointers   With the introduction of Swift  Apple has documented the performSelector  family of methods as  inherently unsafe  and they are not available to Swift   Over time  we have seen this progression    Early versions of Objective-C allow performSelector   manual memory management  Objective-C with ARC warns for use of performSelector  Swift does not have access to performSelector  and documents these methods as  inherently unsafe    The idea of sending messages based on a named selector is not  however  an  inherently unsafe  feature  This idea has been used successfully for a long time in Objective-C as well as many other programming languages     1 All Objective-C methods have two hidden arguments  self and  cmd that are implicitly added when you call a method   2 Calling a NULL function is not safe in C  The guard used to check for the presence of the controller ensures that we have an object  We therefore know we ll get an IMP from methodForSelector   though it may be  objc msgForward  entry into the message forwarding system   Basically  with the guard in place  we know we have a function to call   3 Actually  it s possible for it to get the wrong info if declare you objects as id and you re not importing all headers  You could end up with crashes in code that the compiler thinks is fine  This is very rare  but could happen  Usually you ll just get a warning that it doesn t know which of two method signatures to choose from   4 See the ARC reference on retained return values and unretained return values for more details

[ios] performSelector may cause a leak because its selector is unknown

Examples related to ios

Examples related to objective-c

Examples related to memory-leaks

Examples related to automatic-ref-counting