état: cela a été vu aussi récemment que Mac OS 10.8 et Xcode 4.4.
tl; dr: Cela peut se produire dans deux contextes: lors de l'exécution sur l'appareil et lors de l'exécution sur le simulateur. Lors de l'exécution sur l'appareil, la déconnexion et la reconnexion de l'appareil semblent résoudre les problèmes.
Mike Ash a suggéré
launchctl list|grep UIKitApplication|awk '{print $3}'|xargs launchctl remove
Ça ne marche pas tout le temps. En fait, cela n'a jamais fonctionné pour moi, mais cela fonctionne clairement dans certains cas. Je ne sais pas quels cas. Cela vaut donc la peine d'essayer.
Sinon, la seule manière connue de résoudre ce problème est de redémarrer l'utilisateur launchd. Le redémarrage le fera, 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 seule fois. Lorsque les choses s'arrêtent, déconnectez-vous en tant que vous-même, connectez-vous en tant qu'utilisateur et tuez le launchd qui appartient à 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. Connectez-vous à nouveau 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, avec un statut de processus de Z en ps.
Le problème principal semble être dans le serveur de noms d'amorçage qui est implémenté dans launchd. Ceci (dans la mesure où je le comprends) mappe les ID d'application aux ports mach. Lorsque le bogue est déclenché, l'application meurt mais n'est pas nettoyée de la carte du serveur de noms du serveur d'amorçage et, par conséquent, le serveur d'amorçage refuse d'autoriser l'enregistrement d'une autre instance de l'application sous le même nom.
On espérait (voir les commentaires) que forcer launchd to wait()pour le zombie résoudrait les choses, mais ce n'est pas le cas. Ce n'est pas le statut de zombie qui est le problème principal (c'est pourquoi certains zombies sont bénins) mais le serveur de noms de bootstrap et il n'y a aucun moyen connu de supprimer ce court-circuit de tuer launchd.
Il semble que le bogue soit déclenché par quelque chose de mauvais entre Xcode, gdb et l'utilisateur launchd. Je viens de répéter le coin en exécutant une application dans le simulateur d'iphone, en la faisant arrêter dans gdb, puis en faisant une construction et en exécutant vers le simulateur d'ipad. Il semble sensible à la commutation des 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é gâchera votre session. Se déconnecter et se reconnecter ne tue pas l'utilisateur launchd; OS X conserve le processus existant. Un redémarrage réparera les choses, mais c'est douloureux. Les instructions ci-dessus sont plus rapides.
J'ai soumis un bogue à Apple, FWIW. rdar: // 10330930