Erreur lors des tests sur le simulateur iOS: impossible de s'enregistrer avec le serveur bootstrap
Je testais mon application sur le simulateur lorsque celle-ci est tombée en panne en cliquant sur un bouton d'un UIAlertView. J'ai arrêté le débogage là-bas, apporté quelques modifications au code et créé à nouveau l'application. Maintenant, quand je lance l'application, j'obtiens cette erreur dans la console
Impossible d'inscrire com.myApp.debug avec le serveur bootstrap. Erreur: code d'erreur inconnu. Cela signifie généralement qu'une autre instance de ce processus était déjà en cours d'exécution ou est bloquée dans le débogueur.Program signal reçu: "SIGABRT".
J'ai essayé de supprimer l'application du simulateur, en effectuant une nouvelle construction, mais je reçois toujours cette erreur lorsque j'essaie d'exécuter l'application.
Que dois-je faire pour pouvoir exécuter à nouveau l'application sur mon simulateur?
Essayez de quitter et de redémarrer le simulateur? Si "le pire arrive au pire", vous pouvez toujours essayer de redémarrer: selon mon expérience, cela devrait régler le problème.
status: cela a été vu récemment comme Mac OS 10.8 et Xcode 4.4.
tl; dr: Cela peut se produire dans deux contextes: lors de l'exécution sur le périphérique et lors de l'exécution sur le simulateur. Lors de l'exécution sur le périphérique, la déconnexion et la reconnexion du périphérique semblent résoudre les problèmes.
launchctl list|grep UIKitApplication|awk '{print $3}'|xargs launchctl remove
Cela ne marche pas tout le temps. En fait, cela n'a jamais fonctionné pour moi mais cela fonctionne clairement dans certains cas. Juste ne sais pas quels cas. Donc ça vaut le coup d'essayer.
Sinon, le seul moyen connu de résoudre ce problème consiste à redémarrer l'utilisateur launchd. Le redémarrage fera cela, mais il existe un moyen moins drastique/plus rapide. Vous devrez créer un autre utilisateur administrateur, mais vous ne devrez le faire qu'une fois. Déconnectez-vous en tant que vous-même, connectez-vous en tant qu'utilisateur et supprimez la commande launchd appartenant à votre utilisateur principal, par exemple,
Sudo kill -9 `ps aux | egrep 'user_id .*[0-9] /sbin/launchd' | awk '{print $2}'`
en remplaçant votre nom d'utilisateur principal par user_id. Reconnectez-vous lorsque votre utilisateur normal vous ramène à un état sain. Un peu douloureux, mais moins qu'un redémarrage complet.
détails:
Cela a commencé à se produire plus souvent avec Lion/Xcode 4.2. (Personnellement, je ne l'ai jamais vu avant cette combinaison.)
Le bogue semble être dans launchd, qui hérite du processus d'application en tant qu'enfant lorsque le débogueur arrête de le déboguer sans le tuer. Cela est généralement signalé par l'application qui devient un zombie et dont l'état du processus est Z dans ps.
Le problème principal semble concerner le serveur de noms bootstrap mis en œuvre dans launchd. Ceci (si je comprends bien) mappe les identifiants d’application sur des ports mach. Lorsque le bogue est déclenché, l'application meurt mais n'est pas nettoyée du mappage du serveur de noms du serveur bootstrap et, par conséquent, le serveur bootstrap refuse d'autoriser une autre instance de l'application. être enregistré sous le même nom.
On espérait (voir les commentaires) que le fait de forcer launchd à wait() pour le zombie réglerait le problème, mais ce n'est pas le cas. Ce n’est pas le statut du zombie qui est le problème principal (c’est pourquoi certains zombis sont bénins), mais le serveur de noms bootstrap et il n’existe aucun moyen connu d’éliminer ce problème à court terme.
Il semble que le bogue soit provoqué par quelque chose de mal entre Xcode, gdb et l'utilisateur launchd. Je viens de répéter le wedge en exécutant une application dans le simulateur d'iphone, en l'arrêtant dans gdb, puis en effectuant une construction et une exécution sur le simulateur d'ipad. Il semble être sensible aux commutateurs de simulateurs (iOS 4.3/iOS 5, iPad/iPhone). Cela n'arrive pas tout le temps mais assez fréquemment lorsque je change souvent de simulateur.
Tuer launchd pendant que vous êtes connecté va bousiller votre session. Se déconnecter et se reconnecter ne tue pas l'utilisateur launchd; OS X conserve le processus existant. Un redémarrage va réparer les choses, mais c'est douloureux. Les instructions ci-dessus sont plus rapides.
J'ai soumis un bogue à Apple, FWIW. rdar: // 10330930
Je constate que j'ai commencé à avoir ce problème avec Lion + Xcode 4.2. J'ai également rencontré le problème dans Xcode 4.3.
J'ai essayé toutes les suggestions mais aucune d’entre elles n’a fonctionné à part un redémarrage complet.
Voici comment déterminer si vous avez besoin d’un redémarrage rapide.
Répertoriez tous vos processus Zombie:
ps -el | grep 'Z'
Si votre application est répertoriée en tant que processus Zombie, vous devrez redémarrer votre ordinateur. Le message d'erreur indique "Cela signifie généralement qu'une autre instance de ce processus était déjà en cours d'exécution ou est bloquée dans le débogueur". Eh bien, Xcode détecte ce processus Zombie que vous ne pouvez pas tuer. Le seul moyen de résoudre ce problème consiste à redémarrer le système. :(
EDIT, 20120823: J'ai une meilleure connaissance des processus Zombie et je voulais donc mettre à jour cette réponse. Un processus Zombie est créé lorsqu'un processus parent n'appelle pas wait () (attend que le processus change d'état) sur un processus enfant qui se termine. Vous ne pouvez pas exécuter "kill" directement sur un processus Zombie, mais si vous supprimez le processus parent, le processus enfant zombie sera "récolté" et supprimé de la table des processus.
Je n'ai pas vu ce problème depuis longtemps, je n'ai donc pas inspecté le processus parent dans ce scénario. L'alternative à la suppression du processus parent consiste à redémarrer votre système. :)
Cela vient de m'arriver: l'erreur ne se produisait que sur mon appareil et le simulateur fonctionnait bien. J'ai fini par avoir à réinitialiser mon appareil et l'erreur a disparu.
J'ai ce problème très souvent récemment. Qu'est-ce qui empêcherait cela? La déconnexion et l'entrée résolvent le problème, mais… c'est agaçant de le faire de temps en temps.
MODIFIER:
Je viens de trouver la cause. J'ai eu un bogue dans la méthode ApplicationWillTerminate. Ainsi, lorsque je clique sur le bouton d'arrêt de la fenêtre Xcode, l'application ne parvient pas à se terminer correctement et commence à se bloquer.
vérifiez le Moniteur d'activité pour voir si votre application est sur la liste. forcer à quitter si possible.
Eh bien, pas de réponses mais au moins un test de plus à faire. Ouvrez Terminal et exécutez cette commande: "ps-Ael | grep Z". Si vous obtenez deux entrées, l'une "(clang)" et l'autre votre nom d'application ou de société, vous êtes condamné - redémarrez.
Si vous êtes un développeur, entrez un bogue court et dites à Apple à quel point le redémarrage est gênant, et mentionnez qu'ils peuvent dupliquer ce bogue pour "rdar: // 10401934" que je viens d'entrer.
David
La réinitialisation du simulateur iOS a corrigé l'erreur pour moi. Bien que cela supprime toutes les applications que vous avez dans Simulator, cela résout le problème sans avoir à redémarrer la machine.
Vous pouvez réinitialiser votre simulateur iOS en procédant comme suit:
1) Allez au menu "Simulateur iOS", à côté du logo Apple () à l'extrême gauche de votre écran principal.
2) Sélectionnez "Réinitialiser le contenu et les paramètres ...".
3) Lisez le message contextuel et si vous êtes d’accord, cliquez sur "Réinitialiser", sinon, cliquez sur "Ne pas réinitialiser".
J'ai eu cette erreur lors du débogage de mon application sur un iPhone 4. Le redémarrage difficile de l'iPhone a résolu mon problème. (Mise hors tension de l'iPhone accroché ...)
Je n'ai eu aucun processus de zombie sur mon mac et le redémarrage du mac n'a pas résolu le problème.
Peut-être que ce bug peut se manifester à la fois sur le simulateur et sur les appareils réels ???
Cette erreur m’arrive souvent, presque à chaque fois que je teste l’application dans le simulateur, ce qui me force à redémarrer.
Voici une solution de contournement si vous souhaitez effectuer un travail:
- Cliquez sur votre projet dans le navigateur de projet.
- Aller cible -> Info
- Ajouter une clé pour L'application ne s'exécute pas en arrière-plan et est définie sur
YES.
Cela signifie que lorsque vous appuyez sur le bouton d'accueil du simulateur ou quittez le simulateur, l'application ne se bloque pas.
N'oubliez pas de modifier ce paramètre avant la distribution! Mettez-le sur votre liste de contrôle de publication :)
Si cela se produit lors de tests sur l'iPhone. Il suffit de redémarrer le téléphone. D'après ce que l'on m'a dit, le téléphone ou le simulateur croit toujours qu'il existe une instance de l'application en cours d'exécution. Par conséquent, lors de la dernière exécution, l'application ne s'était pas terminée correctement. gémissement.
Redémarrez l'appareil, ça marche! :RÉ
Merci à tous pour les bonnes suggestions.
J'ai eu le problème @ jyap mentionne avec les processus de zombies. Le seul moyen de les effacer était de redémarrer. Cependant, j'ai remarqué que mes amis travaillant sur le même projet auraient le même problème mais pourraient tuer le simulateur sans créer de processus zombie. J'ai complètement désinstallé Xcode et je l'ai réinstallé. Bien que le problème persiste, il ne crée pas de processus zombie. Je n'ai donc pas besoin de redémarrer.
Avant cela, j’utilisais cette solution de contournement vraiment laide: modifiez votre identifiant d’application et exécutez-le à nouveau. Vous vous retrouvez avec des copies indésirables de l'application dans le simulateur, mais vous pouvez différer le redémarrage pendant un certain temps.
Solution de rechange:
- Donnez à votre application un nouvel identifiant. S'il s'appelle com.foobar.myapp, appelez-le com.foobar.myapp01
Vous perdez toutes les données de l'application, car il s'agit en fait d'une nouvelle application qui s'exécute en ce qui concerne le simulateur iPhone. Cela peut être ou ne pas être plus ennuyeux que de redémarrer - je voulais juste l’ajouter à la liste.
- Fermer le simulateur
- Arrêtez l'application de s'exécuter en xCode.
- Ouvrez Activity Monitor et recherchez un processus en cours d'exécution avec votre App NAME.
- Tuer ce processus dans le moniteur d'activité
- Reconstruisez votre projet et vous devriez être prêt
J'ai eu le même problème et l'ai résolu en procédant comme suit
- Suppression de l'application de l'appareil,
- Déconnecter l'appareil de Mac,
- Éteindre et rallumer l'appareil,
- Quitter et relancer Xcode,
- Arrêter les instruments,
- Enfin, nettoyez et construisez à nouveau.
J'ai également fait une dernière chose, car Xcode est configuré pour utiliser iOS 5.0 et mon projet utilise iOS 4.3.
- Supprimez tous les cadres et ajoutez-les à nouveau.
J'ai eu un setter récursif qui a balayé la pile et a tué mon application de telle manière que je devais démarrer mon iPad. C'était prouvable avec un correctif dans le code.
La cause
Exécution de votre application dans le simulateur avant que l'application en cours d'exécution ne soit complètement arrêtée.
Le correctif
Attendez de voir le bouton Stop redevenir actif avant de courir à nouveau.
(J'utilise Xcode 4.2.1. Ce problème est survenu très fréquemment lorsque j'ai effectué une mise à niveau vers OS X Lion).
Je viens d'avoir cette erreur. J'ai essayé de redémarrer le simulateur et Xcode, mais mon projet ne fonctionnerait plus qu'après un nettoyage et une construction. Aucune idée de ce qui l'a causé.
Je pense que cela est dû à la fermeture forcée de votre application sur l'iPhone avant d'appuyer sur le bouton d'arrêt dans Xcode. Parfois, lorsque vous appuyez sur le bouton d'arrêt dans Xcode, il faut plus de temps pour quitter l'application si elle se bloque. Mais soyez patient, il finira par s'arrêter la plupart du temps.
Aucune reconstruction ou réinstallation nécessaire pour mon problème, et dans mon cas, l'erreur est apparue lors de la tentative d'exécution de l'application sur l'iPhone. Le simulateur a bien fonctionné.
Solution: supprimez l'application du téléphone, effectuez un redémarrage à froid du téléphone et tout va bien maintenant.
Fixé en redémarrant mon téléphone après avoir supprimé l'application, puis en le reconstruisant propre et en cours d'exécution. Fonctionne bien maintenant.
Bizarre.
Cela m’arrive beaucoup avec Xcode 4.2.1 sur Lion. Mis à jour à la version 4.3.2 et cela ne se produit plus. Heureux ils l'ont réparé.
Mike Ash posté une solution (dieu le bénisse!) Qui ne nécessite pas de redémarrage. Il suffit de courir:
launchctl list|grep UIKitApplication|awk '{print $3}'|xargs launchctl remove
La commande ci-dessus répertorie tous les travaux launchd, en recherche un avec UIKitApplication dans le nom (ce qui correspond au travail correspondant à votre application qui reste mal collé), extrait le nom et demande à launchd de se débarrasser de ce travail.
Vous pouvez affecter une variable dans une fonction ou un onglet. Il sera dealloc si votre fonction ou votre onglet est quitté. Vous devez donc déclarer la variable membre ou la variable globale.
Je recevais cette erreur tout le temps jusqu'à ce que je cesse de faire confiance au bouton "Arrêter" dans la boîte de dialogue Exécuter. Maintenant que je clique toujours sur stop dans la barre d’outils avant d’essayer de courir, je n’ai encore rencontré aucun processus zombie.
Oh mon dieu - j'ai essayé tout ce qui est énuméré ci-dessus et dans d'autres publications. Réinstallez Xcode, redémarrez ma machine, copiez tous les fichiers manquants dans les bons dossiers ... Finalement, j'ai sauvegardé mon iphone, je l'ai effacé et restauré, et tout a fonctionné!
Je pense que ce qui a pu être la cause de la lecture dans et autour de cela était de déconnecter mon iphone blanc, il fonctionnait avec des outils de performance qui attrapaient les fuites. Ou quelque chose comme ça.
Aaaah, grand soupir de soulagement.
Si vous exécutez des tests à partir de la ligne de commande, (en utilisant xcodebuild test), assurez-vous que le simulateur en cours d'exécution correspond au périphérique sur lequel vous comptez exécuter les tests.
Vous exécutez peut-être des tests de ligne de commande utilisant l'iPhone 5. Si vous utilisiez l'iPhone 6 dans XCode puis exécutez les tests en ligne de commande, il peut arriver que l'iPhone 6 continue de fonctionner et que vous deviez sélectionner manuellement le périphérique iPhone 5, puis exécuter les tests à nouveau.
Auparavant, cette erreur se produisait dans les anciennes versions du simulateur iOS car les anciennes instances d'un travail sur un autre périphérique en cours de fermeture pouvaient entrer en collision avec la nouvelle instance.
iOS 6.0 et versions ultérieures ne devraient pas rencontrer de problèmes de ce type car iOS 6.0 a introduit l'utilisation de bootstrap sous-ensembles, et iOS 7.0 a introduit l'utilisation d'un serveur bootstrap dédié (launchd_sim) complètement isolé. à partir du serveur bootstrap de l'hôte.
Dans la pire des conditions Réinitialiser le contenu et les paramètres d'iOS Simulater, et la plupart du temps dans mon cas, quitter XCode avec le simulateur fonctionne toujours pour moi avec XCode4.6 (qui est fréquemment pendu)
J'ai fait face à ce genre de problème une fois dans mon cas, voici ce que j'ai fait
- Supprimer l'application du simulateur.
- Supprimez le dossier de données dérivé.
- Effectuer une action de nettoyage dans le projet en sélectionnant le menu du produit - Nettoyer
- Réinitialiser le simulateur.
- Quittez Xcode.
- Essayez de lancer le projet maintenant si cela fonctionne bien, passez à l'étape 7
- Répétez toutes les étapes 1 à 5, puis redémarrez votre ordinateur.
Dans la plupart des cas, je l'ai exécuté à l'étape 6, dans des cas extrêmes, j'ai dû redémarrer ma machine.