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.
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.
Process: aText [11473] Path: /Applications/aText.app/Contents/MacOS/aText Identifier: com.trankynam.aText Version: 2.19 (62) Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: aText [11473] User ID: 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.
Date/Time: 2018-03-15 00:58:10.552 -0400 OS Version: Mac OS X 10.12.6 (16G1036) Report Version: 12 Anonymous UUID: 6C985CFD-6975-3F30-50EB-0713315F5090 Time Awake Since Boot: 630000 seconds System Integrity Protection: enabled
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.
Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x000040dedeadbec0 Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler [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.
