Normalmente, aplicativos travando em um Mac são muito raros. Mas quando isso acontecer, você pode querer rastrear esses problemas. E se você for um desenvolvedor, você precisa entender por que seu aplicativo está travando. Veja como ler relatórios de falhas do macOS e classificá-los por linguagem criptografada.
Links Rápidos
Relatórios de falha abertos
Quando um aplicativo falha em um Mac, ele gera automaticamente um relatório de falha. Você verá isso aparecer após a falha com uma caixa de diálogo de aviso dizendo “[Aplicativo] parou inesperadamente.” Este relatório de falha está disponível para leitura imediata nesta janela clicando no botão "Relatório ...". Um relatório de falha também pode ser encontrado no aplicativo Console.
1. Abra o aplicativo Console digitando “Console” no Spotlight ou vá para “Aplicativo -> Utilitários -> Console.app”.
2. Clique em "Relatórios do usuário" no menu à esquerda e, a seguir, clique no relatório de falha que deseja visualizar. Todos esses arquivos terminam em ".crash" e incluem a data e o aplicativo corrompido no título. Os detalhes do relatório de falha estão disponíveis no painel à direita.
Leia relatórios de falhas do Mac OS
Vamos ver o relatório de travamento de cima para baixo.
O que caiu?
A primeira parte do relatório de travamento mostra se um processo ou aplicativo "trava". A parte mais importante para o solucionador de problemas é o nome do processo.
Processo: aText [11473] Caminho: /Applications/aText.app/Contents/MacOS/aText Identificador: com.trankynam.aText Versão: 2.19 (62) Tipo de código: X86-64 (Nativo) Processo pai: ??? [1] Responsável: aText [11473] ID do usuário: 501
Quando aconteceram as férias?
A segunda parte nos diz quando a falha ocorreu. Também fornece poucas informações sobre o seu sistema.
Data/Hora: 15/03/2018 00:58:10.552 -0400 Versão do SO: Mac OS 630000 segundos Proteção de Integridade do Sistema: ativada
O que causou o mau funcionamento?
A próxima parte é a mais brilhante. O "tipo de exceção" fornecido pelo aplicativo nos informa a causa do mau funcionamento. Além do log, ele também relata qual thread pegou o jeito: neste caso, thread 0.
Thread com falha: 0 Fila de despacho: com.apple.main-thread Tipo de exceção: EXC_BAD_ACCESS (SIGSEGV) Códigos de exceção: KERN_INVALID_ADDRESS em 0x000040dedeadbec0 Nota de exceção: EXC_CORPSE_NOTIFY Sinal de término: Falha de segmentação: 11 Motivo do término: Namespace SIGNAL, Código 0xb Processo que terminou: manipulador exc [0]
Listas da Apple Alguns tipos comuns de exceções Em sua documentação técnica:
Fraco acesso à memória (EXC_BAD_ACCESS / SIGSEGV / SIGBUS) - O programa tenta acessar a memória incorretamente ou com um endereço inválido. Com código explicando o problema de memória.
Saída anormal (EXC_CRASH / SIGABRT) - saída anormal, geralmente nas mãos de uma exceção C ++ não pendente e uma chamada para abort ()
Trace Trap (EXC_BREAKPOINT / SIGTRAP) - o mesmo que SIGABRT, mas esse encerramento dá ao depurador anexado a chance de interromper o processo em um ponto de interrupção e rastrear o erro.
Instruções ilegais (EXC_BAD_INSTRUCTION / SIGILL) - O processamento emitiu um processamento que não foi compreendido ou não pôde ser resolvido.
Sair (SIGQUIT) - O processo é encerrado por outro processo com privilégios suficientes. Normalmente, o monitoramento acaba com a má conduta.
Terminar (SIGKILL) - O processo foi encerrado a pedido do sistema. O código de saída será anexado para explicar a exceção.
Como podemos ver no relatório de falha, o aplicativo tentou acessar a memória não qualificada. Isso ocorre devido a um bug de programação no aplicativo ou a uma condição incomum do usuário que faz com que o aplicativo mapeie a memória incorretamente.
O que leva ao mau funcionamento?
A seguir, vemos uma lista cronológica reversa do que leva à falha. Eles são classificados por thread, começando com o thread 0.
Existem quatro colunas para este relatório. Os primeiros relatórios referem-se ao número do evento em ordem cronológica inversa, começando em 0. O segundo é o ID do processo. O terceiro é o endereço do processo na memória. O quarto é o nome da tarefa do programa.
Este 'retrocesso' pode ser um pouco confuso. Eles são "simbólicos", o que significa que alguns endereços de memória foram substituídos por nomes de funções ou tarefas de aplicativos. Às vezes, simplesmente não consegue fazer isso completamente, deixando endereços de memória ilegíveis espalhados por todo o relatório.
Vemos isso no relatório de travamento acima: com.trankynam.aText não é simbólico. Mesmo com a codificação completa, o fundo pode ser difícil de ler. Os desenvolvedores de software às vezes incluem notas úteis sobre tarefas e eventos do aplicativo. Outras vezes, são endereços criptografados ou código digital. Se você conseguir entender o simbolismo, poderá entender o que está acontecendo. Mas, tanto quanto possível, você mesmo precisará codificar o aplicativo para entender o backtrace.
Conclusão: isso é útil?
Se você é um desenvolvedor de software, a leitura de relatórios de falhas é obrigatória. Isso ajuda você a entender qual parte do seu aplicativo está causando problemas e por quê. Se você é um usuário, não é útil. Mas se você tiver travamentos persistentes, os relatórios de travamento podem ajudá-lo a solucionar o problema ou trabalhar com o desenvolvedor para corrigi-lo. Você pode obter o código de erro resolvido de maneira útil por meio do Google ou pode enviá-lo ao suporte técnico com as informações corretas. Se você quiser detalhes drásticos, pode ler tudo sobre isso em Nota técnica da Apple sobre travamentos.
