[Débutant] Débugguer un programme - Trouver quel est l'objet qui a telle adresse.
colas_
Membre
[SDK 10.6, Xcode 4.2]
Bonjour,
mon programme me lance l'erreur suivante dans la console :
J'aimerais savoir qui est l'objet 0x1001ca580.
Comment puis-je faire ?
Je sais que ce qui cause problème est la ligne N
Merci !
Bonjour,
mon programme me lance l'erreur suivante dans la console :
<br />
-[NSTextField copyWithZone:]: unrecognized selector sent to instance 0x1001ca580<br />
J'aimerais savoir qui est l'objet 0x1001ca580.
Comment puis-je faire ?
Je sais que ce qui cause problème est la ligne N
- Si je met un breakpoint sur la ligne N, le compilateur s'arrête à cette ligne et me donne des adresses d'objets, mais mon erreur n'est pas encore dans la console. Je sais qui sont les objets, mais je ne sais pas qui va buguer.
- Si je mets le breakpoint juste après la ligne N, j'ai le message d'erreur, mais la fenêtre où s'affichaient les adresses des objets est vide : je ne sais plus qui est qui.
Merci !
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Je pense que tu ne prends pas le problème dans le bon sens... En fait tu devrais plutôt regarder la doc Apple de NSTextField...
Apparemment tu dois essayer d'utiliser la méthode copy qui n'est pas utilisable avec un NSTextField.
Par ailleurs, pour ce genre de question, c'est préférable de mettre le code qui te génère l'erreur...
Je n'ai pas utilisé la méthode copy.
Pour supprimer le bug, j'ai ajouté une @property sur un IBOutlet.
Mais le problème est revenu depuis
Comme je suis débutant, je ne sais pas utiliser le debbugueur.
Je m'imaginais que c'était simple de voir qui est qui (adresses <-> objets) quelque part : ça aurait pu (ou ça pourra) me mettre sur la piste !
Lances toi! Apple doit proposer un tutoriel quelque part! Ce n'est jamais du temps de perdu de commencer par là , d'essayer d'y mettre des points d'arrêt ou d'y faire des modifications!
Après tu nous poseras des questions sur des points précis et nous pourrons te répondre précisément.
Je sais, les débuts sont souvent exaspérants et pénibles.
Une fois que ça a planté, normalement si ça plante dans le même contexte, tu peux le voir aussi. Sauf que ça plante certainement dans une sous-sous-sous-méthode à l'intérieur des frameworks Apple, le temps qu'il se rende compte que tu as essayé d'appeler une méthode qui n'existe pas sur l'objet en question, qu'il essaye quand même de s'en sortir, et finisse par te sortir l'exception, et qu'entre temps tu as perdu la trace de ta variable (que l'objet qui pose problème est dans une variable interne au framework Apple, variable qui n'est pas exposée/visible à l'extérieur donc ne s'affiche pas dans la liste des variables là où tu t'y attendais).
Il faut donc remonter dans le contexte de la méthode où tu as mis le breakpoint, via la "Call Stack" (ou "Pile d'Appels") que tu as dans un des onglets dans le volet de gauche (le même volet où il y a la liste des fichiers dans un onglet, des breakpoints dans un autre, des warning dans un autre...), pour remonter quelques appels plus hauts, dans les méthodes qui ont appelé la méthode qui a planté (donc celle où tu avais mis ton breakpoint à l'origine, dans ton cas). Là tu te retrouveras dans le contexte de ta méthode et retrouveras tes objets avec leurs adresses etc.
Autre possibilité, c'est que tu as un écrasement mémoire et qu'en fait l'adresse en question pointe sur n'importe quoi. Ce qui peut arriver si tu n'utilises pas ARC dans ton projet (qui facilite la gestion mémoire et limite le risque de pointeurs flottants (dandling pointers) ou d'écrasement mémoire) et que tu avais une variable qui pointait sur un NSTextField avant, NSTextField qui a depuis disparu / a été détruit, mais du coup ta variable pointe sur un espèce de reste de ruines de faux NSTextField qui n'en est plus vraiment un, avec l'adresse qui pointe du coup en vrai sur tout autre chose ou sur de la mémoire corrompue... et du coup patatras !
Et pour ça, activer les "Zombies" (NSZombiesEnabled=YES, ou juste la case à cocher dans ton Scheme) aide bien à savoir quel est l'objet qui a été supprimé et sur lequel tu essayes quand même d'appeler des méthodes qui font qu'il s'emmêle les pinceaux et plante.
Mmmm ! Le fouet !! Oui c'est bon. Encore, encore, ...
Ouh là ! Je m'égare là
(petite précision, il semble bien que le fouet c'était pour les variables globales, pas pour la lecture de la doc, mais c'est un détail)
po signifie print object.
ça affiche le résultat de la méthode -description. En l'occurrence, ça doit simplement afficher qu'il s'agit d'un NSTextField à l'adresse 0x1001ca580.
En complément à Ceroce, si c'est un NSTextField parmi d'autres, pour savoir lequel tu peux taper, toujours dans le débugger et en gardant la référence supra
po [0x1001ca580 stringValue]
ça donne la valeur présente du champ et ça permet de repérer lequel plus facilement.
Tu peux aussi regarder dans la console tes variables et tenter de repérer 0x1001ca580 en face d'un nom de variable.
Si ton textfield est partie d'un Controller il y a des chances pour que tu te retrouves dans une des méthodes de ce controller, pour en voir les champs il faudra déplier "self" qui représente le controller dans la colonne de gauche de la console, celle avec un popup Auto.