2010-12-08 4 views
0

Pourquoi lorsque le code suivant (intentionnellement fuit) est exécuté avec l'outil Instrument-Leaks, cela indique-t-il une fuite pour NSObject, mais pas NSDate? Ils apparaissent tous les deux lorsqu'ils sont exécutés avec l'outil Analyser l'analyse statique comme je m'y attendais.Une fuite simple n'apparaît pas dans l'outil Instruments-Leak

#import <Foundation/Foundation.h> 

int main (int argc, const char * argv[]) { 

    NSObject* obj = [NSObject alloc]; 
    obj = [NSObject alloc]; 

    NSDate* date = [NSDate alloc]; 
    date = [NSDate alloc]; 

    sleep(10); // time to allow leaks to pick up sample 
    return 0; 
} 
+0

Oui, j'ai déjà vécu la même chose avant. J'ai aussi essayé intentionnellement des fuites et Instruments ne les a pas détectés. Je suppose que les instruments ne vérifient pas aussi complètement que prévu. – Altealice

+0

Je vous suggère de regarder dans les vidéos WWDC 2010. La session 311 a très bien couvert ce sujet. – JustSid

+0

FYI - Avec les instruments, vous pouvez ajuster la fréquence d'interrogation pour les fuites et réduire le temps de 10 secondes. Je crois que le réglage est appelé «secondes entre les détections automatiques» et se trouve dans le panneau de gauche. –

Répondre

2

Ceci est juste une hypothèse: NSDate pourrait mettre en œuvre des hacks assez durs pour des performances qui rend sa méthode -alloc retourne une valeur en cache.

+0

Non, ce serait totalement contre leur propre philosophie de la mémoire. – JustSid

+1

Cela semble certainement possible. Une façon de tester consiste à ajouter des messages 'initWith ...' à chaque instance afin qu'elle produise des dates différentes et voir si elle fuit. Les initialiseurs Objective-C sont autorisés à renvoyer une instance différente afin que NSDate renvoie simplement un objet factice à partir de alloc. –

+0

J'ai essayé ce qui précède et il a montré des fuites __NSCFDate - merci –

Questions connexes