IPHONE: Analyser les fuites avec des instruments

Question

J'essaie de localiser les fuites à l'aide d'instruments, mais les fuites que je vois sont similaires à celles de l'image suivante:

  

des fuites

Comme vous pouvez le constater, il n’ya aucune information sur la ligne de code qui coule exactement. Toutes les fuites que j'ai, environ 20, sont comme ceci, ou en d'autres termes, les fuites ne montrent aucune ligne de mon code en particulier.

La fuite dans cette image est liée à "_CFAllocatorSystem". (???) sur la CoreFoundation et j'en ai d'autres qui disent simplement GSEvent. Je n'ai aucune idée de ce qui les génère.

Comment puis-je découvrir cela?

merci pour toute aide.

Answer 1

Je pense que vous souhaitez entrer dans les instruments après une fuite sous fuite et sélectionner "Vue de la source". Ensuite, vous devez faire glisser vos fichiers source dans la fenêtre d'instrument. Il affichera ensuite les lignes du code où la fuite se produit avec la pile d'appels.

Certains rejettent le code de la mine avec une vue. Cela ressemble à ceci dans Instruments: texte de remplacement http://img688.imageshack.us/img688/9669/screen20091028at131.png

Answer 2

Ce que Leaks vous montre, c’est la trace du code qui a attribué l’objet qui fuit (ce qui signifie qu’il est conservé mais que votre application n’a plus de variables ayant cette adresse). Cela ne vous montre pas exactement où l'objet aurait dû être libéré pour ne pas causer la fuite, car il est impossible de le savoir (il est possible de savoir où la version est appelée, mais cela risque de ne pas être très utile).

Donc, ce que cette trace me dit, c’est que vous conservez un peu de mémoire allouée par le système, puis la référence est oubliée - l’une des clés est la balise "PurpleEvent". ligne, ce qui est commun dans un thread traitant des événements de minuterie ou peut-être des notifications. Il se peut que vous ayez reçu une notification et en ayez gardé quelque chose sans la relâcher ultérieurement.

Si vous savez à quel moment la fuite se produit, vous devriez pouvoir isoler le code en cours d'exécution pendant ce temps.

Answer 3

Voir ici et plus particulièrement cette citation:

Cette liste vous informe sur les types, tailles, adresses et même les piles d'appels des objets qui ont fui.

Ensuite, vous pouvez rechercher la source des mémoires perdues dans les piles d'appels.

La trace de la pile vous montre exactement quelle ligne est coupable. Apparemment, la ligne 14 à main.m dans votre cas. Vous ne savez pas ce que vous avez confondu?

Answer 4

Le coupable était l'accéléromètre et je compile pour OS 3.0.

En d'autres termes, l'accéléromètre qui, selon Apple, a corrigé ses fuites continue de couler comme si de rien n'était.