L'attachement Xcode au processus n'affiche pas NSLog
Je commence tout juste avec Apple Watch. J'ai trouvé des instructions dans " Five Minute Watchkit ", sur l'exécution de l'application iOS et de l'application Watch Kit dans le simulateur et les deux processus liés au débogueur LLDB.
Ce que je fais est de lancer et quitter l'application iOS pour installer une version actuelle de la carte SIM. Ensuite, je passe au système watchKit et lance celui-ci, qui affiche l'interface utilisateur de l'application de surveillance sur le simulateur de surveillance.
Je lance ensuite l'application iOS correspondante dans le simulateur, puis l'utilisateur "attacher au processus" dans le menu Xcode pour attacher le débogueur à l'application iOS en cours d'exécution.
Cela marche. Je peux définir des points d'arrêt dans le kit de surveillance InterfaceController ou dans mon application iOS. Le débogueur s'arrête là quand il le faut.
Cependant, je ne vois pas d'instructions NSLog () dans la console de débogage à partir de mon application iOS. (Je vois des instructions de journal à partir du code d'extension WatchKit.) Si je définis un point d'arrêt dans mon application iOS, il s'arrête à ce point au moment opportun. Je suppose que l'absence de sortie de console de NSLog a quelque chose à voir avec l'attachement à un processus en cours d'exécution sur la carte SIM plutôt que de le lancer à partir de Xcode, mais je ne sais pas ce que c'est.
(BTW, attacher une action à un point d'arrêt qui appelle NSLog à partir du point d'arrêt ne s'affiche pas non plus, mais la commande de débogage "log message" NE affiche pas . Quelqu'un a-t-il un aperçu?)
EDIT: Le code dans l'application iOS ne semble pas avoir d'importance. Dans mon cas, il s’agissait d’un IBAction très simple qui était associé à un bouton du storyboard de l’application iOS:
- (IBAction)buttonAction:(UIButton *)sender;
{
NSLog(@"Button clicked on iPhone");
}
Je peux définir un point d'arrêt sur cette instruction NSLog. Le débogueur s'arrête à cette ligne, mais l'instruction de journal ne s'affiche pas dans la console de débogage.
Je peux reproduire cela avec une application de test simple, sans WatchKit. L'application se compose d'un NSTimer qui imprime "Timer a tiré" chaque seconde. (Ce code est correct à 100%;). Rien ne s'affiche dans le journal après que je me suis attaché manuellement au processus.
Pour autant que je sache les sorties de NSLog sur stderr, j’imagine que l’attachement du débogueur ne redirige pas stderr vers le terminal Xcode.
Si vous êtes d'accord avec l'utilisation de l'application console ou du terminal pour consulter vos journaux, vous pouvez le faire. iOS8 stocke les journaux de simulateur dans ~/Library/Logs/CoreSimulator/<Device-UUID>. Dans ce répertoire, vous trouverez un fichier system.log, contenant toutes vos sorties NSLog.
Vous pouvez le regarder dans le terminal (cat, grep, tail) ou l'ouvrir dans le fichier Console.app.
Apple confirme cela (au moins pour GDB) dans Note technique TN2239: Magic Debugging Magic .
Sortie de la console
De nombreux programmes, et même de nombreux frameworks système, impriment le débogage messages à stderr. La destination de cette sortie est finalement contrôlé par le programme: il peut rediriger stderr vers n'importe quoi la destination qu'il choisit. Cependant, dans la plupart des cas, un programme ne le fait pas redirect stderr, ainsi la sortie passe à la destination par défaut hérité par le programme de son environnement de lancement. C'est typiquement l'un des suivants:
- Si vous lancez une application graphique comme elle serait lancée par un .__ normal. utilisateur, le système redirige tous les messages imprimés sur stderr vers le fichier journal du système. Vous pouvez visualiser ces messages en utilisant les techniques décrites plus tôt.
- Si vous exécutez un programme dans Xcode, vous pouvez voir son stderr est affiché dans la fenêtre de la console du débogueur de Xcode (choisissez l’élément de menu Console dans le menu Exécuter pour afficher cette fenêtre).
Attachement à un Le programme en cours d'exécution (à l'aide du menu Attacher au processus de Xcode ou de la commande attacher dans GDB) ne connecte pas automatiquement le programme du programme à votre fenêtre GDB. Vous pouvez le faire depuis GDB en utilisant l’astuce décrit dans la section "Visualisation de stdout et stderr après l’attachement" de Note technique TN2030, «GDB for MacsBug Veterans».
La TN2030 mentionnée n’est plus disponible sur son serveur ( miroir ). Il a montré comment vous pouvez rediriger stdout et stderr vers la console Xcode. Cependant, puisque Shell tty n'est pas une commande valide pour LLDB, cela ne vous aidera pas beaucoup. Mais peut-être existe-t-il un moyen différent d'accéder aux utilisations de la console tty Xcodes, aussi j'attache la partie importante de ce TN.
Voir stdout et stderr après la fixation
Si vous associez la GDB à un processus (par opposition au démarrage du processus .__ à partir de GDB), vous ne pourrez rien voir de ce processus imprime sur stdout ou stderr. Programmes généralement lancés par le Finder avoir stdout et stderr connectés à "/ dev/console", donc les informations ils impriment vont à la console. Vous pouvez voir cela en lançant le fichier Application console (dans le dossier Utilitaires), cependant, il s’agit de gênant de devoir regarder dans une fenêtre séparée. Une autre alternative est de connecter le stdout ou stderr du processus au terminal pour la fenêtre de terminal de GDB. Le Listing 9 montre comment faire cela.
Listing 9. Connexion de stdout et stderr au terminal de GDB.
(gdb) attach 795 [... output omitted ...] (gdb) call (void) DebugPrintMenuList() No output )-: Close the stdout and stderr file descriptors. (gdb) call (void) close(1) (gdb) call (void) close(2) Determine the name of the terminal device for GDB itself. (gdb) Shell tty /dev/ttyp1 Reopen stdout and stderr, but connected to GDB's terminal. The function results should be 1 and 2; if not, something is horribly wrong. (gdb) call (int) open("/dev/ttyp1", 2, 0) $1 = 1 (gdb) call (int) open("/dev/ttyp1", 2, 0) $2 = 2 Try the DebugPrintMenuList again. (gdb) call (void) DebugPrintMenuList() Yay output! Index MenuRef ID Title ----- ---------- ---- ----- <regular menus> 00001 0x767725D3 -21629 Ed 00002 0x76772627 1128 <Apple> 00003 0x767726CF 1129 File 00004 0x76772567 1130 Edit [... remaining output omitted ...]
Pour ajouter à la réponse Filipp Keks, voici une représentation visuelle d'une manière beaucoup plus simple de le faire que la réponse acceptée.
De la réponse de Filipp Keks: "1) Branchez le périphérique et ouvrez Xcode
2) Choisissez Fenêtre -> Périphériques dans la barre de menus.
3) Dans la section DEVICES de la colonne de gauche, choisissez le périphérique.
4) Pour voir la console du périphérique, cliquez sur le triangle situé en bas à gauche du panneau de droite.
5) Cliquez sur la flèche en bas à droite pour enregistrer la console en tant que fichier "
Cette capture d'écran a été prise dans Xcode 7.3.1 de la fenêtre Périphériques.
Avec Xcode Version 7.2 et iOS 9.2, etc., j'ai trouvé les travaux suivants:
0) Tuer le téléphone et regarder les applications
1) Sélectionnez Watch Watch Target et appuyez sur Cmd+R (construire et courir)
2) Sélectionnez la cible du téléphone et appuyez sur Ctrl+Cmd+R (Courir sans construire)
Dans mon cas, j'ai les deux applications dans leurs simulateurs et j'obtiens une sortie NSLog pour les deux. Je n'ai pas besoin d'attacher séparément. J'espère que cela t'aides.
https://developer.Apple.com/library/ios/qa/qa1747/_index.html
1) Branchez le périphérique et ouvrez Xcode
2) Choisissez Fenêtre -> Périphériques dans la barre de menus.
3) Dans la section DEVICES de la colonne de gauche, choisissez le périphérique.
4) Pour voir la console du périphérique, cliquez sur le triangle situé en bas à gauche du panneau de droite.
5) Cliquez sur la flèche en bas à droite pour enregistrer la console sous forme de fichier.
Lorsque votre profil de provisioning est défini sur AdHoc ou Distribution, Xcode n’affiche pas le journal, vous devez définir le développement pour pouvoir afficher le journal.