iOS – erro estranho ao testar no simulador

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

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

Eu tentei remover o aplicativo do simulador, fazendo uma compilation limpa, mas ainda assim recebo esse erro quando tento executar o aplicativo.

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

Tente desistir e reiniciar o simulador? Se “o pior acontecer”, você pode sempre tentar reiniciar: na minha experiência, isso deve resolvê-lo.

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

tl; dr: Isso pode ocorrer em dois contextos: ao executar no dispositivo e ao executar no simulador. Quando executado 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 funciona claramente 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 reboot fará isso, mas há uma maneira menos drástica / mais rápida. Você precisará criar outro usuário administrador, mas só precisa fazer isso uma vez. Quando as coisas se encheckboxm, efetue o logout como você mesmo, efetue login como esse 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 por user_id . Efetuando login novamente como seu usuário normal, você volta para um estado sã. Meio doloroso, mas menos do que uma reboot completa.

detalhes:

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

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

O problema central parece estar no servidor de nomes de bootstrap que é implementado no launchd. Isso (até onde eu entendi) mapeia ids de aplicativos para portas mach. Quando o bug é acionado, o aplicativo morre, mas não é limpo do mapa do servidor de nomes do servidor de autoboot e, como resultado, o servidor de autoboot se recusa a permitir que outra instância do aplicativo seja registrada com o mesmo nome.

Esperava-se (veja os comentários) que forçar o launchd a wait() pelo zumbi consertaria as coisas, mas isso não acontece. Não é o status de zumbi que é o problema central (é por isso que alguns zumbis são benignos), mas o servidor de nomes de bootstrap e não há nenhuma maneira conhecida de eliminar este curto lançamento de killd.

Parece que o bug é acionado por algo ruim entre o Xcode, o gdb e o user launchd. Acabei de repetir o processo executando um aplicativo no simulador do iPhone, interrompendo-o no gdb e, em seguida, fazendo uma compilation e executando o simulador de ipad. Parece ser sensível à troca de simuladores (iOS 4.3 / iOS 5, iPad / iPhone). Isso não acontece o tempo todo, mas com bastante frequência quando eu estou trocando muito de simuladores.

Matar o launchd enquanto estiver logado irá estragar sua session. Fazer o logout e logar de volta não mata o usuário launchd; O OS X mantém o processo existente. Uma reboot consertará as coisas, mas isso é doloroso. As instruções acima são mais rápidas.

Eu 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 reboot completa.

Aqui está como você determina se você precisa de uma reboot rapidamente.

Listar todos os seus processos de zumbis:

 ps -el | grep 'Z' 

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

EDIT, 20120823: Eu tenho um conhecimento melhor dos processos do Zombie, então eu queria atualizar essa resposta. Um processo Zombie é criado quando um processo pai não chama wait () (espera que o processo mude de estado) em um processo filho de finalização. Você não pode executar ‘kill’ diretamente em um processo Zombie, mas se você matar o processo pai, o processo filho zumbi 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 é reinicializar seu sistema. 🙂

Acabei de acontecer isso comigo: eu estava recebendo o erro apenas no meu dispositivo e o simulador estava funcionando bem. Eu acabei tendo que redefinir meu dispositivo e o erro foi embora.

Estou tendo esse problema com muita frequência recentemente. O que impediria que isso ocorresse? Sair e corrigir 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 eu clico no botão Parar na janela do Xcode, o aplicativo não pode terminar corretamente e começar a travar.

verifique o Activity Monitor para ver se o seu aplicativo está na lista. force sair, se possível.

Se você achar que seu problema é devido a processos de zumbis:

  ps -el |  grep 'Z' 

(como no comentário anterior https://stackoverflow.com/a/8104400/464289 ) e só quer corrigir o problema imediatamente, você pode fazê-lo sem reiniciar ou matar qualquer coisa. Apenas renomeie o executável de destino do projeto:

  1. Clique no projeto no painel esquerdo
  2. Selecione Configurações de compilation 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 para fazer. Abra o Terminal e execute este comando: “ps-Ael | grep Z”. Se você receber duas inputs, uma “(clang)” e outra o nome do seu aplicativo ou empresa, você terá a opção de “reinicializar”.

Se você é um desenvolvedor, digite um bug curto e diga à Apple como é absolutamente irritante ter que reinicializar, e mencione que eles podem usar 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ê tem no Simulador, ele corrige o problema sem precisar reiniciar a máquina.

Você pode redefinir seu simulador do iOS fazendo o seguinte:

1) Vá para o menu “Simulador do iOS”, ao lado do logotipo Apple () na extremidade esquerda da canvas 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”.

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

Antes de fazer isso, estava usando essa solução realmente desagradável: altere o ID do aplicativo e execute novamente. Você acaba com cópias inúteis do aplicativo no simulador, mas pode adiar a reboot por um tempo.

Este erro acontece muito para mim, quase toda vez que eu testar 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 do projeto
  • Ir Alvo -> Info
  • Adicionar uma chave para o aplicativo não é executado em segundo plano e definido como YES .

Isso significa que quando você aperta 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 em sua lista de lançamentos 🙂

Se isso acontecer ao testar no iPhone. Apenas reinicie o telefone. Pelo que me disseram, o telefone ou simulador ainda acredita que há uma instância do aplicativo em execução, portanto, quando foi executado pela última vez, ele não foi encerrado corretamente devido a um erro no seu código ou o telefone / simulador só queria ter um gemido.

Eu recebi este erro ao depurar meu aplicativo em um iPhone 4. A reboot do iPhone resolveu meu problema. (Desligando o iPhone pendurado …)

Eu não tive nenhum processo de zumbi no meu mac e reiniciar o mac não resolveu o problema.

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

Reiniciei o dispositivo, funcionou! : D

Obrigado a todos pelas ótimas sugestões.

Eu acabei de ter esse erro. Tentei reiniciar o simulador e o Xcode mas o meu projeto só funcionaria novamente depois de um clean e build. Não faço ideia do que causou isso.

Eu tinha um setter recursivo que explodiu pela pilha e matou meu aplicativo de tal forma que eu tive que ligar o meu iPad. Foi comprovado com uma correção no código.

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

Eu tive o mesmo problema e resolvi fazendo o seguinte

  • Excluindo o aplicativo do dispositivo,
  • Desconectando o dispositivo do Mac,
  • Desligando e ligando o aparelho,
  • Parando e relançando o Xcode,
  • Parando Instrumentos,
  • Finalmente, limpe e construa novamente.

Eu 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ê um novo identificador ao seu aplicativo. Se for chamado com.foobar.myapp, chame-o com.foobar.myapp01

Você perde todos os dados no aplicativo, pois é um novo aplicativo em execução no que diz respeito ao simulador do iPhone. Isso pode ou não ser mais irritante do que reinicializar – só queria adicioná-lo à lista.

A causa

Executando seu aplicativo no Simulador antes que o aplicativo anteriormente em execução parasse completamente.

O conserto

Espere até ver o botão Parar novamente ativo antes de executar novamente.

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

Corrigido pela reboot do meu telefone depois de excluir o aplicativo, em seguida, reconstruí-lo limpo e funcionando novamente. Funciona bem agora.

Esquisito.

Nenhuma reconstrução ou reinstalação necessária para o meu problema, e no meu caso, o erro apareceu ao tentar executar o aplicativo no iPhone. Simulador funcionou bem.

Solução: Apague o aplicativo do telefone, faça um reinício a frio do telefone e agora tudo está bem.

Aconteceu muito para mim 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 requer uma reboot. Apenas corra:

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

O comando acima lista todos os jobs de launchd, procura um com o UIKitApplication no nome (que será o trabalho correspondente ao seu aplicativo que está impropriamente ligado), extrai o nome e informa ao launchd para se livrar desse job.

Acho que isso é causado pelo encerramento forçado do 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 ele estiver suspenso. Mas apenas seja paciente, acabará desistindo a maior parte do tempo.

Você pode atribuir variável na function ou guia. Ele será desalocado se sua function ou guia for encerrada. Então você deve declarar variável de membro ou variável global.

Eu estava recebendo esse erro o tempo todo até que eu parei de confiar no botão “Stop” na checkbox de diálogo Executar. Agora que sempre clico em parar 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 que faltavam nas pastas certas … Eventualmente eu fiz backup do meu iphone, limpei e restaurei, e funcionou!

Eu acho que o que pode ter sido a causa da leitura e em torno disso foi desconectar meu iphone branco estava correndo com ferramentas de desempenho pegando vazamentos. Ou algo assim.

Aaaah, grande suspiro de alívio.

Na pior das hipóteses, redefinir o conteúdo e configuração do iOS Simulater, e na maioria das vezes no meu caso, sair do XCode junto com o simulador, sempre funciona para mim com XCode4.6 (que freqüentemente são enforcados)

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. Executar uma ação limpa no projeto, selecionando o menu do produto – limpo
  4. Repor o simulador.
  5. Saia do Xcode.
  6. Tente executar o projeto agora, se estiver funcionando bem, vá para o passo 7
  7. Repita todas as etapas de 1 a 5 e, em seguida, reinicie sua máquina.

Na maioria dos casos eu comecei a correr no passo 6 casos extremos eu tive que reiniciar minha máquina.

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

O iOS 6.0 e posterior não deve ter problemas como este porque o iOS 6.0 introduziu o uso de subconjuntos de boot e o iOS 7.0 introduziu o uso de um servidor de boot dedicado (launchd_sim) que é completamente isolado do servidor de boot do host.