2009-09-18 9 views
2

La plupart du temps lorsque le programme Iphone se bloque, le compilateur affiche pile avec plein de non, mais ces non n'ont aucun sens pour moi. Très rarement, il indique où le problème pourrait être et surtout il y a ces non inutiles. Comment vous assurer que lorsque votre programme se bloque en cours de développement/test, cela montre à quel endroit cela provoque ce crash?Le rapport de crash et de pile du programme IPhone montré par le compilateur est totalement inutile!

+0

Vous pourriez avoir plus de chance si vous postez un exemple d'une telle pile-trace. – Beardy

+0

Eh bien, je ne peux pas pointer ici un exemple particulier, cela arrive chaque fois que le programme plante! – itsaboutcode

Répondre

3

Ma vie iPhone dev était horrible jusqu'à ce que je trouve NSZombieEnabled. En ajoutant ce drapeau dans votre exécutable, il vous aidera à voir les problèmes de mémoire en vous indiquant le nom de l'objet en faute.

Cela fonctionne en ne libérant jamais réellement un objet, mais en l'enveloppant comme un "zombie" et en plaçant un drapeau à l'intérieur qui dit qu'il aurait normalement été libéré. De cette façon, si vous essayez d'y accéder à nouveau, vous savez toujours ce que c'était avant de faire l'erreur, et avec ce petit peu d'information, vous pouvez généralement revenir en arrière pour voir quel était le problème.

Il aide en particulier dans les threads d'arrière-plan lorsque le débogueur manque parfois d'informations utiles.

TRÈS IMPORTANT DE REMARQUER Cependant, c'est que vous devez vous assurer à 100% que c'est seulement dans votre code de débogage et pas votre code de distribution. Parce que rien ne sortira jamais, votre application va fuir et fuir et fuir. Pour me rappeler de cela, je mets ce journal dans mon appdelegate:

if(getenv("NSZombieEnabled") || getenv("NSAutoreleaseFreedObjectCheckEnabled")) 
    NSLog(@"NSZombieEnabled/NSAutoreleaseFreedObjectCheckEnabled enabled!"); 
+0

Merci, je pense que cela va résoudre certains de mes problèmes, ce sera génial dans le cas où vous cherchez des fuites de mémoire possible, mais je me demandais si cela sera utile dans les cas de crash? – itsaboutcode

+0

il est seulement utile dans les cas de plantage - les cas de plantage qui sont dus aux problèmes de mémoire qui sont la plupart d'entre eux. – coneybeare

0

Choses à faire:

1) Mise au point avec point d'arrêt sur

2) Ajouter un point d'arrêt global: objc_exception_throw

Ensuite, regardez dans la fenêtre Débogueur

1

Le mot clé que vous recherchez est « symbolicate ». Si vous avez un journal de plantage d'un appareil, vous devez symboliser le soleil pour que la trace de la pile vous donne les numéros de ligne.

La fonction que j'ai dans mon .profile pour me aider à exécuter la commande est:

function desym 
{ 
/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash -A -v $1 | more 
} 

Fondamentalement, vous mettez le paquet d'application, le fichier dsym généré lors de la compilation, et le journal des blocages dans le même répertoire et exécutez ensuite "dysm [CrashLog File Name]" pour que les symboles s'affichent correctement dans la trace de la pile.

Notez qu'il doit être être le même exécutable et le fichier dysm qui a généré le crash! Chaque fois que vous recompilez, les emplacements des choses peuvent changer.

Questions connexes