Erro ao testar no simulador do iOS: não foi possível registrar-se no servidor de autoinicialização

Eu estava testando meu aplicativo no simulador quando ele travou ao clicar em um botão de um UIAlertView. Parei de depurar lá, fiz algumas alterações no código e construí o aplicativo novamente. Agora, quando executo o aplicativo, recebo esse erro no console

Não foi possível registrar o com.myApp.debug no servidor de auto-inicialização. Erro: código de erro desconhecido. Isso geralmente significa que outra instância desse processo já estava em execução ou está travada no depurador. Sinal recebido pelo programa: “SIGABRT”.

Tentei remover o aplicativo do simulador, fazendo uma compilação limpa, mas ainda recebo esse erro ao tentar executá-lo.

O que devo fazer para poder executar o aplicativo no meu simulador novamente?

Tente sair e reiniciar o simulador? Se "o pior vem a pior", você sempre pode tentar reiniciar: na minha experiência, isso deve corrigi-lo.

status: isso foi visto recentemente no Mac OS 10.8 e no Xcode 4.4.

tl; dr: Isso pode ocorrer em dois contextos: quando rodando no dispositivo e rodando no simulador. Ao executar no dispositivo, desconectar e reconectar o dispositivo parece consertar as coisas.

Mike Ash sugeriu

launchctl list|grep UIKitApplication|awk '{print $3}'|xargs launchctl remove

Isso não funciona o tempo todo. Na verdade, nunca funcionou para mim, mas claramente funciona em alguns casos. Só não sei quais casos. Então vale a pena tentar.

Caso contrário, a única maneira conhecida de corrigir isso é reiniciar o usuário launchd. A reinicialização fará isso, mas há uma maneira menos drástica / rápida. Você precisará criar outro usuário administrador, mas precisará fazer isso apenas uma vez. Quando as coisas se complicarem, efetue logout como você mesmo, efetue login como usuário e elimine o launchd que pertence ao seu usuário principal, por exemplo,

sudo kill -9 `ps aux | egrep 'user_id .*[0-9] /sbin/launchd' | awk '{print $2}'`

substituindo seu nome de usuário principal user_id. Efetue login novamente, pois seu usuário normal o levará de volta ao estado normal. Meio doloroso, mas menos do que uma reinicialização completa.

detalhes:

Isso começou a acontecer com mais frequência com o Lion / Xcode 4.2. (Pessoalmente, eu nunca vi isso antes dessa combinação.)

O bug parece estar no launchd, que herda o processo do aplicativo como um filho quando o depurador para de depurá-lo sem matá-lo. Isso geralmente é sinalizado pelo aplicativo se tornar um zumbi, com um status de processo de Z no ps.

O problema principal parece estar no servidor de nome de autoinicialização implementado no launchd. Isso (na medida em que eu entendo) mapeia os IDs de aplicativos para as portas mach. Quando o bug é acionado, o aplicativo morre, mas não é limpo do mapa do servidor de nomes do servidor de inicialização e, como resultado, o servidor de inicialização se recusa a permitir que outra instância do aplicativo seja registrada com o mesmo nome.

Esperava-se (ver os comentários) que forçar o launchd wait()para o zumbi consertasse as coisas, mas não o faz. Não é o status de zumbi que é o principal problema (e é por isso que alguns zumbis são benignos), mas o servidor de nome de autoinicialização e não há maneira conhecida de resolver esse problema.

Parece que o bug foi acionado por algo ruim entre o Xcode, gdb e o usuário launchd. Acabei de repetir a cunha executando um aplicativo no simulador do iphone, interrompendo-o no gdb e fazendo uma compilação e execução no simulador de ipad. Parece ser sensível aos simuladores de comutação (iOS 4.3 / iOS 5, iPad / iPhone). Isso não acontece o tempo todo, mas com bastante frequência quando eu mudo muito de simulador.

Matar launchd enquanto você estiver logado estragará sua sessão. Efetuar logout e logon novamente não mata o usuário launchd; OS X mantém o processo existente por perto. Uma reinicialização corrigirá as coisas, mas isso é doloroso. As instruções acima são mais rápidas.

Enviei um bug para a Apple, FWIW. rdar: // 10330930

Acho que comecei a ter esse problema com o Lion + Xcode 4.2. Eu também experimentei o problema no Xcode 4.3.

Eu tentei todas as sugestões, mas nenhuma delas funcionou além de uma reinicialização completa.

Aqui está como você determina se precisa de uma reinicialização rapidamente.

Liste todos os seus processos Zombie:

ps -el | grep 'Z'

Se você vir seu aplicativo listado como um processo Zombie, precisará reiniciar sua máquina. A mensagem de erro informa "Isso geralmente significa que outra instância desse processo já estava em execução ou está travada no depurador". Bem, o Xcode está detectando esse processo de zumbi que você não pode matar. A única maneira de corrigi-lo é com uma reinicialização do sistema. :(

EDIT, 20120823: Conheci melhor os processos do Zombie, por isso desejei atualizar esta resposta. Um processo Zombie é criado quando um processo pai não chama wait () (aguarde o processo mudar de estado) em um processo filho final. Você não pode executar 'kill' diretamente em um processo Zombie, mas se você matar o processo pai, o processo filho zombie será 'colhido' e removido da tabela de processos.

Não vejo esse problema há muito tempo, portanto não inspecionei para ver qual é o processo pai nesse cenário. A alternativa para matar o processo pai é reiniciar o sistema. :)

Acabei de acontecer: estava recebendo o erro apenas no meu dispositivo e o simulador estava funcionando bem. Acabei tendo que redefinir meu dispositivo e o erro desapareceu.

Estou tendo esse problema com muita frequência recentemente. O que impediria que isso acontecesse? Sair e entrar corrige o problema, mas ... é irritante fazer isso de vez em quando.

EDITAR:

Acabei de encontrar a causa. Eu tive um bug no método ApplicationWillTerminate. Então, quando clico no botão Parar na janela do Xcode, o aplicativo não pode terminar corretamente e começa a travar.

verifique o Activity Monitor para ver se seu aplicativo está na lista. forçar o encerramento, se possível.

Se você achar que seu problema se deve a processos zumbis:

ps -el | grep 'Z'

1. Clique no projeto no painel esquerdo
2. Selecione Configurações de compilação no painel do meio
3. Em ' Embalagem ', altere ' Nome do produto ' de $ (TARGET_NAME) para $ (TARGET_NAME) .1

Fácil!

Bem, não há respostas, mas pelo menos mais um teste a fazer. Abra o Terminal e execute este comando: "ps-Ael | grep Z". Se você receber duas entradas, uma "(clang)" e a outra o nome do aplicativo ou da empresa, você receberá uma mangueira - reinicie.

Se você é um desenvolvedor, insira um pequeno bug e diga à Apple o quão irritante é a reinicialização e mencione que eles podem enganar esse bug para "rdar: // 10401934", que acabei de inserir.

David

A redefinição do simulador do iOS corrigiu o erro para mim. Embora isso remova todos os aplicativos que você possui no Simulator, ele corrige o problema sem precisar reiniciar a máquina.

Você pode redefinir seu Simulador iOS fazendo o seguinte:

1) Vá para o menu "iOS Simulator", ao lado do logotipo da Apple () na extrema esquerda da tela principal.
2) Selecione "Redefinir conteúdo e configurações ...".
3) Leia a mensagem pop e, se você concordar, clique em "Redefinir", caso contrário, clique em "Não redefinir".

1. Fechar simulador
2. Pare a execução do aplicativo no xCode.
3. Abra o Activity Monitor e procure um processo em execução com o seu NOME do Aplicativo .
4. Mate esse processo no Activity Monitor
5. Reconstrua seu projeto e você deve estar pronto

Eu tive o problema @jyap menciona com processos zumbis. A única maneira de limpá-los era reiniciar. No entanto, notei que meus amigos que trabalhavam no mesmo projeto receberiam o mesmo problema, mas poderiam matar o simulador sem criar um processo de zumbi. Eu desinstalei completamente o Xcode e reinstalei-o, e enquanto ainda recebo o erro, ele não cria processos zumbis, portanto, não preciso reiniciar.

Antes de fazer isso, eu estava usando essa solução realmente feia: altere o ID do aplicativo e execute novamente. Você acaba com cópias indesejadas do aplicativo no simulador, mas pode adiar a reinicialização por um tempo.

Esse erro acontece muito comigo, quase toda vez que eu testo o aplicativo no Simulador, forçando-me a reiniciar.

Aqui está uma solução alternativa, se você quiser fazer algum trabalho:

• Clique no seu projeto no navegador de projetos
• Go Target -> Informações
• Adicionar uma chave para o aplicativo não é executado em segundo plano e definido como YES.

Isso significa que, quando você pressiona o botão home no simulador ou sai do simulador, o aplicativo não trava.

Não se esqueça de alterar essa configuração antes da distribuição! Coloque-o na sua lista de verificação de lançamento :)

Se isso acontecer ao testar no iPhone. Basta reiniciar o telefone. Pelo que me foi dito, o telefone ou simulador ainda acredita que existe uma instância do aplicativo em execução; portanto, quando foi executado pela última vez, ele não havia terminado corretamente, pode resultar em um erro no seu código ou no telefone / simulador só queria ter um gemido.

Eu recebi esse erro ao depurar meu aplicativo em um iPhone 4. A reinicialização forçada do iPhone resolveu meu problema. (Desligando o iPhone travado ...)

Eu não tive nenhum processo zumbi no meu mac e a reinicialização do mac não resolveu o problema.

Talvez esse bug possa se manifestar no simulador e nos dispositivos reais ???

Reiniciou o dispositivo, funcionou! : D

Obrigado a todos pelas ótimas sugestões.

Eu apenas tive esse erro. Tentei reiniciar o simulador e o Xcode, mas meu projeto só funcionaria novamente após uma limpeza e compilação. Não faço ideia do que causou isso.

Eu tinha um setter recursivo que explodiu na pilha e matou meu aplicativo de tal maneira que tive que inicializar com força o meu iPad. Foi comprovável com uma correção no código.

Eu tive o mesmo problema e o resolvi fazendo o seguinte

• Excluindo o aplicativo do dispositivo,
• Desconectando o dispositivo do Mac,
• Desligando e ligando o dispositivo,
• Sair e reiniciar o Xcode,
• Desistir de instrumentos,
• Finalmente, limpe e construa novamente.

Também fiz mais uma coisa, porque o Xcode está configurado para usar o iOS 5.0 e meu projeto usa o iOS 4.3

• Remova todas as estruturas e adicione-as novamente.

Solução alternativa:

• Dê ao seu aplicativo um novo identificador. Se for chamado com.foobar.myapp, chame-o com.foobar.myapp01

Você perde todos os dados no aplicativo, pois na verdade é um novo aplicativo sendo executado no que diz respeito ao simulador do iPhone. Isso pode ou não ser mais irritante do que reiniciar - só queria adicioná-lo à lista.

A causa

Executando seu aplicativo no Simulador antes que o aplicativo em execução anterior tenha parado completamente.

O conserto

Aguarde até ver o botão Parar se tornar ativo novamente antes de executar novamente.

(Estou usando o Xcode 4.2.1. Esse problema aconteceu com muita frequência quando eu atualizei para o OS X Lion).

Corrigido ao reiniciar meu telefone depois de excluir o aplicativo e, em seguida, reconstruí-lo limpo e executando novamente. Funciona bem agora.

Esquisito.

Não é necessário reconstruir ou reinstalar o problema e, no meu caso, o erro apareceu ao tentar executar o aplicativo no iPhone. Simulador funcionou bem.

Solução: exclua o aplicativo do telefone, faça uma reinicialização a frio do telefone e agora está tudo bem.

Aconteceu muito comigo com o Xcode 4.2.1 no Lion. Atualizado para 4.3.2 e isso não acontece mais. Ainda bem que eles consertaram.

Mike Ash postou uma solução (que Deus o abençoe!) Que não exija reinicialização. Apenas corra:

launchctl list|grep UIKitApplication|awk '{print $3}'|xargs launchctl remove

O comando acima lista todos os trabalhos launchd, procura um com UIKitApplication no nome (que será o trabalho correspondente ao seu aplicativo que está incorretamente instalado), extrai o nome e diz ao launchd para se livrar desse trabalho.

Eu acho que isso é causado pela saída forçada do seu aplicativo no iPhone antes de pressionar o botão Parar no Xcode. Às vezes, quando você pressiona o botão Parar no Xcode, leva um tempo extra para sair do aplicativo, se estiver travado. Mas seja paciente, ele acabará saindo na maioria das vezes.

Você pode alocar variável na função ou guia. Será desalocado se sua função ou guia for encerrada. Portanto, você deve declarar variável de membro ou variável global.

Eu estava recebendo esse erro o tempo todo até parar de confiar no botão "Parar" na caixa de diálogo Executar. Agora que sempre pressiono stop na barra de ferramentas antes de tentar executar, ainda não encontrei nenhum processo zumbi.

Oh meu - eu tentei TUDO listado acima e em outros posts. Reinstalei o Xcode, reiniciei minha máquina, copiei todos os arquivos ausentes para as pastas certas ... Eventualmente, fiz backup do meu iphone, limpei e restaurei, e funcionou!

Eu acho que o que pode ter sido a causa da leitura em torno disso foi desconectar meu iphone, pois ele estava funcionando com ferramentas de desempenho que estavam vazando. Ou algo assim.

Aaaah, grande suspiro de alívio.

Na pior das hipóteses, redefinir o conteúdo e a configuração do iOS Simulater e, na maioria das vezes, sair do XCode junto com o simulador, sempre funciona para mim com o XCode4.6 (que geralmente é travado)

Eu enfrentei esse tipo de problema uma vez no meu caso, aqui está o que eu fiz

1. Exclua o aplicativo do simulador.
2. Exclua a pasta de dados derivados.
3. Execute uma ação de limpeza no projeto, selecionando o menu do produto - limpar
4. Redefina o simulador.
5. Saia do Xcode.
6. Tente executar o projeto agora, se estiver funcionando bem, vá para a etapa 7
7. Repita todas as etapas de 1 a 5 e reinicie a máquina.

Na maioria dos casos, eu o executei na etapa 6 casos extremos e tive que reiniciar minha máquina.

Esse erro costumava ocorrer em versões mais antigas do iOS Simulator porque instâncias mais antigas de um trabalho em outro dispositivo que estava sendo encerrado podiam colidir com a nova instância.

O iOS 6.0 e versões posteriores não devem ter problemas como esse, porque o iOS 6.0 introduziu o uso de subconjuntos de auto-inicialização e o iOS 7.0 introduziu o uso de um servidor de auto-inicialização dedicado (launchd_sim) completamente isolado do servidor de auto-inicialização do host.