Question performSelector peut provoquer une fuite car son sélecteur est inconnu


Je reçois l'avertissement suivant par le compilateur ARC:

"performSelector may cause a leak because its selector is unknown".

Voici ce que je fais:

[_controller performSelector:NSSelectorFromString(@"someMethod")];

Pourquoi ai-je cet avertissement? Je comprends que le compilateur ne peut pas vérifier si le sélecteur existe ou non, mais pourquoi cela causerait-il une fuite? Et comment puis-je changer mon code pour ne plus recevoir cet avertissement?


1189
2017-08-10 20:23


origine


Réponses:


Solution

Le compilateur avertit à ce sujet pour une raison. Il est très rare que cet avertissement soit simplement ignoré et qu'il soit facile de contourner le problème. Voici comment:

if (!_controller) { return; }
SEL selector = NSSelectorFromString(@"someMethod");
IMP imp = [_controller methodForSelector:selector];
void (*func)(id, SEL) = (void *)imp;
func(_controller, selector);

Ou plus lacunaire (bien que difficile à lire et sans le garde):

SEL selector = NSSelectorFromString(@"someMethod");
((void (*)(id, SEL))[_controller methodForSelector:selector])(_controller, selector);

Explication

Qu'est-ce qui se passe ici, vous demandez au contrôleur pour le pointeur de la fonction C pour la méthode correspondant au contrôleur. Tout NSObjects répondre à methodForSelector:mais vous pouvez aussi utiliser class_getMethodImplementation dans le runtime Objective-C (utile si vous avez seulement une référence de protocole, comme id<SomeProto>). Ces pointeurs de fonction sont appelés IMPs, et sont simples typedefpointeurs de fonction ed (id (*IMP)(id, SEL, ...))1. Cela peut être proche de la signature de la méthode, mais ne correspondra pas toujours exactement.

Une fois que vous avez le IMP, vous devez le convertir en un pointeur de fonction qui inclut tous les détails dont ARC a besoin (y compris les deux arguments cachés implicites) self et _cmd de chaque appel de méthode Objective-C). Ceci est traité à la troisième ligne (le (void *) sur le côté droit indique simplement au compilateur que vous savez ce que vous faites et ne pas générer d'avertissement car les types de pointeurs ne correspondent pas).

Enfin, vous appelez le pointeur de fonction2.

Exemple complexe

Lorsque le sélecteur prend des arguments ou renvoie une valeur, vous devrez changer les choses un peu:

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;

Raisonnement pour l'avertissement

La raison de cet avertissement est qu'avec ARC, le runtime doit savoir quoi faire avec le résultat de la méthode que vous appelez. Le résultat pourrait être n'importe quoi: void, int, char, NSString *, idARC obtient normalement ces informations de l'en-tête du type d'objet avec lequel vous travaillez.3

Il y a vraiment seulement 4 choses que l'ARC considérerait pour la valeur de retour:4

  1. Ignorer les types non-objet (void, int, etc)
  2. Conserver la valeur de l'objet, puis relâcher quand il n'est plus utilisé (hypothèse standard)
  3. Libérer de nouvelles valeurs d'objet lorsqu'elles ne sont plus utilisées (méthodes dans le init/ copy famille ou attribué avec ns_returns_retained)
  4. Ne rien faire & supposer que la valeur de l'objet retourné sera valide dans la portée locale (jusqu'à ce que le pool de version le plus interne soit drainé, attribué avec ns_returns_autoreleased)

L'appel à methodForSelector: suppose que la valeur de retour de la méthode appelée est un objet, mais ne le conserve pas / ne le libère pas. Ainsi, vous pourriez finir par créer une fuite si votre objet est censé être libéré comme dans # 3 ci-dessus (c'est-à-dire que la méthode que vous appelez retourne un nouvel objet).

Pour les sélecteurs, vous essayez d'appeler ce retour void ou d'autres non-objets, vous pouvez activer les fonctionnalités du compilateur pour ignorer l'avertissement, mais cela peut être dangereux. J'ai vu Clang passer par quelques itérations de la façon dont il gère les valeurs de retour qui ne sont pas affectées aux variables locales. Il n'y a pas de raison que ARC activé ne peut pas conserver et libérer la valeur d'objet renvoyée par methodForSelector:même si vous ne voulez pas l'utiliser. Du point de vue du compilateur, c'est un objet après tout. Cela signifie que si la méthode que vous appelez, someMethod, retourne un non objet (y compris void), vous pourriez vous retrouver avec une valeur de pointeur de poubelle conservée / libérée et se bloquer.

Arguments supplémentaires

Une considération est que c'est le même avertissement se produira avec performSelector:withObject: et vous pourriez rencontrer des problèmes similaires en ne déclarant pas comment cette méthode consomme des paramètres. ARC permet de déclarer paramètres consomméset si la méthode consomme le paramètre, vous finirez probablement par envoyer un message à un zombie et tomber en panne. Il existe des moyens de contourner ce problème avec le casting en pont, mais il serait vraiment préférable d'utiliser simplement le IMP et la méthodologie du pointeur de fonction ci-dessus. Étant donné que les paramètres consommés sont rarement un problème, il est peu probable que cela se produise.

Sélecteurs statiques

Fait intéressant, le compilateur ne se plaindra pas des sélecteurs déclarés statiquement:

[_controller performSelector:@selector(someMethod)];

La raison en est que le compilateur est en mesure d'enregistrer toutes les informations sur le sélecteur et l'objet lors de la compilation. Il n'a pas besoin de faire des suppositions à propos de quoi que ce soit. (J'ai vérifié cela il y a un an en regardant la source, mais je n'ai pas de référence pour le moment.)

Suppression

En essayant de penser à une situation où la suppression de cet avertissement serait nécessaire et la conception de code bonne, je viens vide. Quelqu'un s'il vous plaît partager si elles ont eu une expérience où le silence de cet avertissement était nécessaire (et ce qui précède ne gère pas les choses correctement).

Plus

Il est possible de construire un NSMethodInvocation pour gérer cela aussi, mais cela nécessite beaucoup plus de frappe et est également plus lent, donc il n'y a pas de raison de le faire.

Histoire

Quand le performSelector: famille de méthodes a d'abord été ajouté à Objective-C, ARC n'existait pas. Lors de la création d'ARC, Apple a décidé qu'un avertissement devait être généré pour ces méthodes afin de guider les développeurs vers l'utilisation d'autres moyens pour définir explicitement comment la mémoire devrait être gérée lors de l'envoi de messages arbitraires via un sélecteur nommé. En Objective-C, les développeurs peuvent faire cela en utilisant des jets de style C sur les pointeurs de fonctions brutes.

Avec l'introduction de Swift, Apple a documenté la performSelector: famille de méthodes comme "intrinsèquement dangereuses" et ils ne sont pas disponibles pour Swift.

Au fil du temps, nous avons vu cette progression:

  1. Les premières versions d'Objective-C permettent performSelector: (gestion manuelle de la mémoire)
  2. Objective-C avec ARC met en garde contre l'utilisation de performSelector:
  3. Swift n'a pas accès à performSelector: et documente ces méthodes comme "intrinsèquement dangereuses"

L'idée d'envoyer des messages basés sur un sélecteur nommé n'est cependant pas une fonctionnalité "intrinsèquement dangereuse". Cette idée a été utilisée avec succès pendant longtemps dans Objective-C ainsi que de nombreux autres langages de programmation.


1 Toutes les méthodes Objective-C ont deux arguments cachés, self et _cmd qui sont implicitement ajoutés lorsque vous appelez une méthode.

2Appel d'un NULL la fonction n'est pas sûre en C. La garde utilisée pour vérifier la présence du contrôleur vérifie que nous avons un objet. Nous savons donc que nous aurons un IMP de methodForSelector: (bien que cela puisse être _objc_msgForward, entrée dans le système de transmission de message). Fondamentalement, avec la garde en place, nous savons que nous avons une fonction à appeler.

3 En fait, il est possible qu'il obtienne la mauvaise information si vous déclarez des objets comme id et vous n'importez pas tous les en-têtes. Vous pourriez vous retrouver avec des plantages dans le code que le compilateur pense très bien. C'est très rare, mais cela pourrait arriver. Habituellement, vous recevrez simplement un avertissement indiquant qu'il ne sait pas laquelle des deux signatures de méthodes choisir.

4 Voir la référence ARC sur valeurs de retour retenues et valeurs de retour non retenues pour plus de détails.


1142
2017-11-18 21:44



Dans le compilateur LLVM 3.0 dans Xcode 4.2, vous pouvez supprimer l'avertissement comme suit:

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-performSelector-leaks"
    [self.ticketTarget performSelector: self.ticketAction withObject: self];
#pragma clang diagnostic pop

Si vous obtenez l'erreur à plusieurs endroits et que vous souhaitez utiliser le système de macro C pour masquer les pragmas, vous pouvez définir une macro pour faciliter la suppression de l'avertissement:

#define SuppressPerformSelectorLeakWarning(Stuff) \
    do { \
        _Pragma("clang diagnostic push") \
        _Pragma("clang diagnostic ignored \"-Warc-performSelector-leaks\"") \
        Stuff; \
        _Pragma("clang diagnostic pop") \
    } while (0)

Vous pouvez utiliser la macro comme ceci:

SuppressPerformSelectorLeakWarning(
    [_target performSelector:_action withObject:self]
);

Si vous avez besoin du résultat du message effectué, vous pouvez le faire:

id result;
SuppressPerformSelectorLeakWarning(
    result = [_target performSelector:_action withObject:self]
);

1170
2017-10-28 19:30



Ma conjecture à ce sujet est la suivante: puisque le sélecteur est inconnu du compilateur, ARC ne peut pas appliquer la gestion de la mémoire appropriée.

En fait, il y a des moments où la gestion de la mémoire est liée au nom de la méthode par une convention spécifique. Plus précisément, je pense à constructeurs de commodité contre faire méthodes les premiers renvoient par convention un objet autoréalisé; ce dernier est un objet retenu. La convention est basée sur les noms du sélecteur, donc si le compilateur ne connaît pas le sélecteur, il ne peut pas appliquer la règle de gestion de la mémoire appropriée.

Si cela est correct, je pense que vous pouvez utiliser votre code en toute sécurité, à condition de vous assurer que tout va bien pour la gestion de la mémoire (par exemple, que vos méthodes ne retournent pas les objets qu'ils allouent).


206
2017-08-10 20:43



Dans votre projet Paramètres de construction, en dessous de Autres drapeaux d'avertissement (WARNING_CFLAGS), ajouter
-Wno-arc-performSelector-leaks

Maintenant, assurez-vous que le sélecteur que vous appelez n'entraîne pas la conservation ou la copie de votre objet.


119
2017-10-31 13:57



Comme une solution de contournement jusqu'à ce que le compilateur permette de remplacer l'avertissement, vous pouvez utiliser l'exécution

objc_msgSend(_controller, NSSelectorFromString(@"someMethod"));

au lieu de

[_controller performSelector:NSSelectorFromString(@"someMethod")];

Tu devras

#import <objc/message.h>


110
2017-08-16 04:56



Pour ignorer l'erreur uniquement dans le fichier avec le sélecteur d'exécution, ajoutez un #pragma comme suit:

#pragma clang diagnostic ignored "-Warc-performSelector-leaks"

Cela ignorerait l'avertissement sur cette ligne, mais l'autorisera tout au long de votre projet.


87
2018-01-18 21:31



Étrange mais vrai: si c'est acceptable (c'est-à-dire que le résultat est nul et que cela ne vous dérange pas de laisser le cycle runloop une fois), ajoutez un délai, même s'il est nul:

[_controller performSelector:NSSelectorFromString(@"someMethod")
    withObject:nil
    afterDelay:0];

Cela supprime l'avertissement, vraisemblablement parce qu'il rassure le compilateur qu'aucun objet ne peut être retourné et en quelque sorte mal géré.


67
2017-11-11 19:19



Voici une macro mise à jour basée sur la réponse donnée ci-dessus. Celui-ci devrait vous permettre d'envelopper votre code même avec une déclaration de retour.

#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]
);

34
2018-05-07 14:58



Ce code n'implique pas de drapeaux de compilateur ou d'appels d'exécution directs:

SEL selector = @selector(zeroArgumentMethod);
NSMethodSignature *methodSig = [[self class] instanceMethodSignatureForSelector:selector];
NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:methodSig];
[invocation setSelector:selector];
[invocation setTarget:self];
[invocation invoke];

NSInvocation permet de définir plusieurs arguments si différents performSelector Cela fonctionnera sur n'importe quelle méthode.


31
2018-02-01 15:46



Eh bien, beaucoup de réponses ici, mais comme c'est un peu différent, en combinant quelques réponses que je pensais mettre. J'utilise une catégorie NSObject qui vérifie pour s'assurer que le sélecteur retourne void, et supprime aussi le compilateur Attention.

#import <Foundation/Foundation.h>
#import <objc/runtime.h>
#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

20
2018-02-21 04:32