Simbolizando relatórios de falhas de aplicativos para iPhone

Estou procurando tentar simbolizar os relatórios de falhas do meu aplicativo para iPhone.

Recuperei os relatórios de falhas do iTunes Connect. Eu tenho o aplicativo binário que enviei para a App Store e o arquivo dSYM que foi gerado como parte da compilação.

Eu tenho todos esses arquivos juntos dentro de um único diretório que é indexado pelo holofote.

E agora?

Eu tentei invocar:

symbolicatecrash crashreport.crash myApp.app.dSYM

e apenas gera o mesmo texto que está no relatório de falha, não simbolizado.

Estou fazendo algo errado?

Etapas para analisar o relatório de falha da apple:

1. Copie o arquivo .app de liberação que foi enviado para a appstore, o arquivo .dSYM criado no momento do lançamento e o relatório de falha receba do APPLE em uma PASTA .

2. Abra o aplicativo do terminal e vá para a pasta criada acima (usando o cdcomando)

3. Corra atos -arch armv7 -o APPNAME.app/APPNAME MEMORY_LOCATION_OF_CRASH. O local da memória deve ser aquele em que o aplicativo falhou conforme o relatório.

Ex: atos -arch armv7 -o 'APPNAME.app'/'APPNAME' 0x0003b508

Isso mostraria a linha exata, o nome do método que resultou em falha.

Ex: [classname functionName:]; -510

Simbolizando IPA

se usarmos o IPA para simbolizar - basta renomear a extensão .ipa com .zip, extraí-lo e obter uma pasta de carga que contém o aplicativo. Nesse caso, não precisamos do arquivo .dSYM.

Nota

Isso só funciona se o binário do aplicativo não tiver símbolos removidos. Por padrão, as compilações de versão retiram os símbolos. Podemos alterá-lo nas configurações de construção do projeto "Retirar símbolos de depuração durante a cópia" para NÃO.

Mais detalhes, veja este post

Depois de ler todas essas respostas aqui para simbolizar um log de falha (e finalmente ter êxito), acho que há alguns pontos ausentes aqui que são realmente importantes para determinar por que a chamada do symbolicatecrash não produz uma saída simbolizada.

Existem três ativos que precisam ser ajustados ao simbolizar um log de falha:

1. O próprio arquivo de log de falha (ou seja, example.crash ), exportado do organizador do XCode ou recebido do iTunes Connect.
2. O .apppacote (por exemplo example.app) que contém o binário do aplicativo pertencente ao log de falha. Se você possui um .ipapacote (ie example.ipa), pode extraí-lo .appdescompactando o .ipapacote (ie unzip example.ipa). Posteriormente, o .apppacote reside no extraídoPayload/ pasta .
3. O .dSYMpacote que contém os símbolos de depuração (ie example.app.dSYM)

Antes de iniciar a simbolização, você deve verificar se todos esses artefatos correspondem, o que significa que o log de falha pertence ao binário que você possui e que os símbolos de depuração são os produzidos durante a construção desse binário.

Cada binário é referido por um UUID que pode ser visto no arquivo de log de falha:

...
Binary Images:
0xe1000 -    0x1f0fff +example armv7  <aa5e633efda8346cab92b01320043dc3> /var/mobile/Applications/9FB5D11F-42C0-42CA-A336-4B99FF97708F/example.app/example
0x2febf000 - 0x2fedffff  dyld armv7s  <4047d926f58e36b98da92ab7a93a8aaf> /usr/lib/dyld
...

Nesta extração, o log de falha pertence a uma imagem binária do aplicativo chamada exemplo.app/example com UUID aa5e633efda8346cab92b01320043dc3 .

Você pode verificar o UUID do pacote binário que você possui com o dwarfdump:

dwarfdump --uuid example.app/example
UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app/example

Depois, você deve verificar se os símbolos de depuração que você também pertencem a esse binário:

dwarfdump --uuid example.app.dSYM
UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app.dSYM/Contents/Resources/DWARF/example

Neste exemplo, todos os ativos se encaixam e você deve poder simbolizar seu rastreamento de pilha.

Prosseguindo para o symbolicatecrashscript:

No Xcode 8.3, você poderá chamar o script via

/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash -v example.crash 2> symbolicate.log

Se não estiver lá, você pode executar um find . -name symbolicatecrashno diretório Xcode.app para encontrá-lo.

Como você pode ver, não há mais parâmetros dados. Portanto, o script precisa encontrar os símbolos binários e de depuração do aplicativo executando uma pesquisa de destaque. Ele pesquisa os símbolos de depuração com um índice específico chamado com_apple_xcode_dsym_uuids. Você pode fazer essa pesquisa você mesmo:

mdfind 'com_apple_xcode_dsym_uuids = *'

resp.

mdfind "com_apple_xcode_dsym_uuids == AA5E633E-FDA8-346C-AB92-B01320043DC3"

A primeira chamada de destaque fornece todos os pacotes dSYM indexados e a segunda fornece os .dSYMpacotes com um UUID específico. Se os holofotes não encontrarem o seu .dSYMpacote, symbolicatecrasheles também não encontrarão . Se você fizer tudo isso, por exemplo, em uma subpasta do seu ~/Desktopholofote, você poderá encontrar tudo.

Se symbolicatecrashencontrar o seu .dSYMpacote, deve haver uma linha como a seguinte em symbolicate.log:

@dsym_paths = ( <SOME_PATH>/example.app.dSYM/Contents/Resources/DWARF/example )

Para encontrar seu .apppacote, uma pesquisa de destaque como a seguinte é invocada por symbolicatecrash:

mdfind "kMDItemContentType == com.apple.application-bundle && (kMDItemAlternateNames == 'example.app' || kMDItemDisplayName == 'example' || kMDItemDisplayName == 'example.app')"

Se symbolicatecrashencontrar o seu .apppacote, deve haver o seguinte extrato em symbolicate.log:

Number of symbols in <SOME_PATH>/example.app/example: 2209 + 19675 = 21884
Found executable <SOME_PATH>/example.app/example
-- MATCH

Se todos esses recursos forem encontrados symbolicatecrash, deve imprimir a versão simbolizada do seu log de falhas.

Caso contrário, você pode passar seus arquivos dSYM e .app diretamente.

symbolicatecrash -v --dsym <SOME_PATH>/<App_URI>.app.dSYM/<APP_NAME>.app.dsym <CRASHFILE> <SOME_OTHER_PATH>/<APP_NAME>.app/<APP_NAME> > symbolicate.log

Nota: O backtrace simbolizado será enviado para o terminal, não symbolicate.log.

Com a versão mais recente do Xcode (3.2.2), você pode arrastar e soltar todos os relatórios de falhas na seção Device Logs do Xcode Organizer e eles serão automaticamente simbolizados para você. Acho que isso funciona melhor se você criou essa versão do aplicativo usando Build & Archive (também parte do Xcode 3.2.2)

Fiz isso com sucesso, usando as etapas a seguir.

Etapa 1: Crie uma pasta na área de trabalho, nomeie-a como "CrashReport" e coloque três arquivos ("MYApp.app", "MyApp.app.dSYM", "MYApp_2013-07-18.crash") nela.

Etapa 2: Abra o Finder e vá para Aplicativos, onde você encontrará o aplicativo Xcode, clique com o botão direito do mouse e clique em "Mostrar Conteúdo do Pacote", depois siga este caminho simples. "Conteúdo-> Desenvolvedor-> Plataformas-> iPhoneOS.platform-> Desenvolvedor-> Biblioteca-> PrivateFrameworks- > DTDeviceKit.framework -> Versões- > A-> Recursos"

OU

"Conteúdo-> Desenvolvedor-> Plataformas-> iPhoneOS.platform-> Desenvolvedor-> Biblioteca-> PrivateFrameworks- > DTDeviceKitBase.framework -> Versões- > A-> Recursos"

OU

Para o Xcode 6 e acima, o caminho é Applications / Xcode.app / Contents / SharedFrameworks / DTDeviceKitBase.framework / Versions / A / Resources

Onde você encontrar o arquivo "symbolicatecrash", copie-o e cole-o na pasta "CrashReport".

Etapa 3: inicie o terminal, execute estes 3 comandos

1. cd / Usuários / mac38 / Desktop / CrashReport e pressione o botão Enter

2. exporte DEVELOPER_DIR = "/ Aplicativos / Xcode.app / Contents / Developer" e pressione Enter

3. ./symbolicatecrash -A -v MYApp_2013-07-18.crash MyApp.app.dSYM e pressione Enter Agora está pronto.

Etapas para simbolizar um relatório de falha automaticamente usando o XCode:

ATUALIZADO PARA XCODE 9

1. Conecte qualquer dispositivo iOS ao seu Mac (sim, físico, sim, eu sei que isso é estúpido)

2. Escolha "Dispositivos" no menu "Janela"

3. Clique no seu dispositivo à esquerda e VEJA LOGS DO DISPOSITIVO à direita

4. Esperar. Pode demorar um minuto para aparecer. Talvez fazendo Command-A, em seguida, Deleteirá acelerar o processo.

5. Passo indocumentados crítica: renomear o relatório acidente que você tem de iTunesConnect de.txtextensão para.crashextensão

6. Arraste o relatório de falha para a área à esquerda

E então o Xcode simbolizará o relatório de falha e exibirá os resultados.

Fonte: https://developer.apple.com/library/ios/technotes/tn2151/_index.html

Uso o Airbrake nos meus aplicativos, o que faz um bom trabalho no registro remoto de erros.

Aqui está como eu os simbolizo com fortes se o backtrace precisar:

1. No Xcode (4.2), vá para o organizador, clique com o botão direito do mouse no arquivo no qual o arquivo .ipa foi gerado.

2. No Terminal, faça o cd no xcarchive, por exemploMyCoolApp 10-27-11 1.30 PM.xcarchive

3. Digite o seguinte atos -arch armv7 -o 'MyCoolApp.app'/'MyCoolApp' (não esqueça as aspas simples)

4. Não incluo meu símbolo nessa ligação. O que você recebe é um cursor de bloco em uma linha vazia.

5. Em seguida, copio / colo meu código de símbolo no cursor do bloco e pressiono enter. Você verá algo como:

   -[MyCoolVC dealloc] (in MyCoolApp) (MyCoolVC.m:34)

6. Você voltou ao cursor do bloco e pode colar outros símbolos.

Ser capaz de percorrer um item de backtrace sem voltar a inserir o primeiro bit economiza bastante tempo.

Aproveitar!

Também coloquei dsym, pacote de aplicativos e log de falha juntos no mesmo diretório antes de executar a falha simbólica

Então eu uso essa função definida no meu .profile para simplificar a execução de symbolicatecrash:

function desym
{
    /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash -A -v $1 | more
}

Os argumentos adicionados lá podem ajudá-lo.

Você pode verificar se os holofotes "veem" seus arquivos dysm executando o comando:

mdfind 'com_apple_xcode_dsym_uuids = *'

Procure o dsym que você possui em seu diretório.

NOTA: A partir do Xcode mais recente, não há mais um diretório Developer. Você pode encontrar este utilitário aqui:

/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Vers‌ions / A / Resources / symbolicatecrash

Apenas uma resposta simples e atualizada para o xcode 6.1.1.

PASSOS

1.Xcode> Janela> Dispositivos.

2. Selecione um dispositivo de uma lista de dispositivos na seção DISPOSITIVOS.

3. Selecione Exibir registros do dispositivo.

Na seção Todos os logs, você pode arrastar e soltar o relatório diretamente.

5.Xcode simboliza automaticamente o relatório de falha para você.

6.Você pode encontrar o relatório de falha simbolizado combinando sua data / hora com a data / hora mencionada no relatório de falha.

Mesmo desenvolvendo aplicativos há alguns anos, essa foi a primeira vez que depurei um binário e me senti como um NOOB completo para descobrir onde estavam todos os arquivos, ou seja, onde estão os arquivos * .app * .dSYM e os registros de falhas? Eu tive que ler várias postagens para descobrir. A imagem vale mais que mil palavras e espero que este post ajude outras pessoas no futuro.

1- Primeiro, acesse o itunesconnect e faça o download dos logs de falha. NOTA: Na maioria dos casos, você pode receber algo como "Poucos relatórios foram enviados para que um relatório seja mostrado". Basicamente, poucos usuários enviaram relatórios de log de falhas à Apple; nesse caso, você não pode fazer nada nesse ponto.

2- Agora, se você não alterou seu código desde que o enviou para a Apple, execute o Xcode para esse projeto e faça Produto -> Arquivar novamente. Caso contrário, encontre o seu último binário enviado e clique com o botão direito nele.

No Xcode 4.2.1, abra o Organizer , vá para Biblioteca / Logs do dispositivo e arraste o arquivo .crash para a lista de logs de falha. Será simbolizado para você depois de alguns segundos.

Observe que você deve usar a mesma instância do Xcode em que a compilação original foi arquivada (ou seja, o arquivo da compilação deve existir no Organizer ).

Usando o Xcode 4, a tarefa é ainda mais simples:

• Organizador aberto ,
• clique em Biblioteca | Log do dispositivo na coluna esquerda
• clique no botão " Importar " na parte inferior da tela ...

e voilà. O arquivo de log é importado e simbolizado automaticamente para você. Desde que você arquive a construção usando o Xcode -> Produto -> Arquivar primeiro.

O mágico Xcode Organizer não é tão mágico em simbolizar meu aplicativo. Não tenho símbolos para os relatórios de falha que voltei da Apple devido a falha no envio de aplicativos.

Tentei usar a linha de comando, colocando o relatório de falha na mesma pasta que o arquivo .app (que enviei para a loja) e o arquivo .dSYM:

$ symbolicatecrash "My App_date_blahblah-iPhone.crash" "My App.app"

Isso forneceu apenas símbolos para o meu aplicativo e não o código básico da base, mas foi melhor do que o número dump que o Organizer está me fornecendo e foi o suficiente para encontrar e corrigir a falha do meu aplicativo. Se alguém souber como estender isso para obter os símbolos da Fundação, seria apreciado.

No meu caso, eu estava arrastando relatórios de falhas diretamente do Mail para o Organizer. Por alguma razão, isso impediu que os relatórios de falhas fossem simbolizados (eu adoraria saber o porquê).

Copiar os relatórios de falhas para a área de trabalho primeiro e depois arrastá-los de lá para o Organizer os simboliza adequadamente.

Caso muito específico, eu sei. Mas pensei em compartilhar apenas por precaução.

Aqui está outro problema que tenho com o symbolicatecrash - ele não funciona com aplicativos que têm espaços no pacote (por exemplo, 'Test App.app'). Nota: não acho que você possa ter espaços em seus nomes ao enviar, portanto, remova-os de qualquer maneira, mas se você já tiver falhas que precisam ser analisadas, corrija o patch simbólico (4.3 GM) como tal:

240c240
<         my $cmd = "mdfind \"kMDItemContentType == com.apple.application-bundle && kMDItemFSName == $exec_name.app\"";
---
>         my $cmd = "mdfind \"kMDItemContentType == com.apple.application-bundle && kMDItemFSName == '$exec_name.app'\"";
251c251
<             my $cmd = "find \"$archive_path/Products\" -name $exec_name.app";
---
>             my $cmd = "find \"$archive_path/Products\" -name \"$exec_name.app\"";

Para aqueles que usam o Airbrake, há uma resposta sólida acima, mas não funcionaria para mim sem ajustar:

Funciona para alguns endereços de memória, mas não para outros, não sei por que ...

• Crie um novo diretório na área de trabalho ou em qualquer lugar
• Encontre o arquivo em questão no organizador do Xcode
• Toque duas vezes para revelar no localizador
• Toque duas vezes para mostrar o conteúdo do pacote
• Copie os arquivos .dSYM e .app para o novo diretório
• cd em novo dir
• Execute este comando: atos -arch armv7 -o 'Vimeo.app' / 'Vimeo'
• Terminal entrará em um movimento interativo
• Cole o endereço da memória e pressione enter; ele exibirá o nome do método e o número da linha
• Como alternativa, digite este comando: atos -arch armv7 -o 'Vimeo.app' / 'Vimeo' Para obter informações sobre apenas um endereço

A combinação que funcionou para mim foi:

1. Copie o arquivo dSYM no diretório em que o relatório de falha foi
2. Descompacte o arquivo ipa que contém o aplicativo ('descompacte MyApp.ipa')
3. Copie o binário do aplicativo da carga útil explodida resultante na mesma pasta que o relatório de falha e o arquivo de símbolo (algo como "MyApp.app/MyApp")
4. Importe ou re-simbolize o relatório de falha do organizador do Xcode

Usando os atos fortes , não consegui resolver as informações corretas dos símbolos com os endereços e compensações contidos no relatório de falha. Quando fiz isso, vi algo mais significativo e parece ser um rastreamento de pilha legítimo.

Eu tive que fazer muita pirataria no script symbolicatecrash para que ele funcionasse corretamente.

Até onde eu sei, o symbolicatecrash agora exige que o .app esteja no mesmo diretório que o .dsym. Ele usará o .dsym para localizar o .app, mas não usará o dsym para encontrar os símbolos.

Você deve fazer uma cópia do seu simbolismo antes de tentar esses patches, que farão com que pareça no dsym:

Em torno da linha 212 na função getSymbolPathFor_dsymUuid

212     my @executablePath = grep { -e && ! -d } glob("$dsymdir" . "/Contents/Resources/DWARF/" . $executable);

Em torno da linha 265 na função matchUUID

265             return 1;

Isso é simples, depois de pesquisar bastante, encontrei etapas claras para simbolizar todo o arquivo de log de falha.

• copie os arquivos .app, crash_report e DSYM em uma pasta.
• conecte o dispositivo com o xcode
• Em seguida, vá para a janela -> selecione dispositivos -> visualizar logs de dispositivos
• Em seguida, selecione este dispositivo, exclua todos os logs.
• arraste e solte sua falha na seção de log do dispositivo. simbolizará automaticamente a falha. basta clicar com o botão direito do mouse no relatório e exportá-lo.

feliz codificação,
Riyaz

Prefiro um script que simbolize todos os meus logs de falha.

Condições prévias

Crie uma pasta e coloque lá 4 coisas:

1. symbolicatecrash script perl - existem muitas respostas SO que indicam sua localização

2. O arquivo da compilação que corresponde às falhas (do Xcode Organizer. Simples como Show in Findere copiar) [não sei se isso é necessário]

3. Todos os xccrashpointpacotes - (do Xcode Organizer. Show in Finder, Você pode copiar todos os pacotes no diretório ou o único xccrashpoint que deseja simbolizar)

4. Adicione esse script curto ao diretório:

   #!/bin/sh
   
   echo "cleaning old crashes from directory"
   rm -P *.crash
   rm -P *.xccrashpoint
   rm -r allCrashes
   echo "removed!"
   echo ""
   echo "--- START ---"
   echo ""
   
   mkdir allCrashes
   mkdir symboledCrashes
   find `ls -d *.xccrashpoint` -name "*.crash" -print -exec cp {} allCrashes/ \;
   
   cd allCrashes
   for crash in *.crash; do
       ../symbolicatecrash $crash > ../symboledCrashes/V$crash
   done
   cd ..
   
   echo ""
   echo "--- DONE ---"
   echo ""

O Script

Ao executar o script, você terá 2 diretórios.

1. allCrashes- todas as falhas de todo o xccrashpointestarão lá.

2. symboledCrashes - as mesmas falhas, mas agora com todos os símbolos.

3. você não precisa limpar o diretório de falhas antigas antes de executar o script. ele será limpo automaticamente. boa sorte!

Descobri que a maioria das alternativas propostas não funcionava no XCode mais recente (testado com o Xcode 10). Por exemplo, não tive sorte em arrastar e soltar logs .crash no Xcode -> Organizer -> Device logs -view.

Eu recomendo usar a ferramenta Symbolicator https://github.com/agentsim/Symbolicator

• Git clone o repositório do Symbolicator e compile e execute com o Xcode
• Copie o arquivo .crash (arquivo ascii, com rastreamento de pilha no início do arquivo) e .xarchive do release com falha na mesma pasta temporária
• Arraste e solte o arquivo .crash no ícone Symbolicator no Dock
• Em 5 a 30 segundos, o arquivo de falha simbólico é produzido na mesma pasta que .crash e .xarchive.

Para simbolizar falhas, o Spotlight deve ser capaz de encontrar o arquivo .dSYM que foi gerado ao mesmo tempo que o binário que você enviou à Apple. Como contém as informações do símbolo, você ficará sem sorte se não estiver disponível.

Fiquei um pouco irritado com o fato de nada aqui parecer "apenas funcionar", então fiz algumas investigações e o resultado é:

Configuração: back-end do QuincyKit que recebe relatórios. Nenhuma simbolização foi criada, pois eu nem conseguia começar a descobrir o que eles estavam sugerindo que eu fizesse para que funcionasse.

A correção: faça o download online dos relatórios de falha do servidor. Eles são chamados de 'falha' e, por padrão, vão para a pasta ~ / Downloads /. Com isso em mente, esse script "fará a coisa certa" e os relatórios de falhas serão inseridos no Xcode (Organizer, registros do dispositivo) e a simbolização será feita.

O script:

#!/bin/bash
# Copy crash reports so that they appear in device logs in Organizer in Xcode

if [ ! -e ~/Downloads/crash ]; then 
   echo "Download a crash report and save it as $HOME/Downloads/crash before running this script."
   exit 1
fi

cd ~/Library/Logs/CrashReporter/MobileDevice/
mkdir -p actx # add crash report to xcode abbreviated
cd actx

datestr=`date "+%Y-%m-%d-%H%M%S"`

mv ~/Downloads/crash "actx-app_"$datestr"_actx.crash"

As coisas podem ser automatizadas para onde você pode arrastar e soltar no Xcode Organizer fazendo duas coisas se você usar o QuincyKit / PLCR.

Primeiro, você deve editar o script remoto admin / actionapi.php ~ line 202. Parece que não obtém o registro de data e hora correto, então o arquivo termina com o nome 'crash' que o Xcode não reconhece (ele quer algo travamento de ponto):

header('Content-Disposition: attachment; filename="crash'.$timestamp.'.crash"');

Em segundo lugar, no lado do iOS no QuincyKit BWCrashReportTextFormatter.m ~ linha 176, altere @"[TODO]"para @"TODO"contornar os caracteres incorretos.

atos está sendo descontinuado, portanto, se você estiver executando o OSX 10.9 ou posterior, poderá ser necessário

xcrun atos

Aviso: / usr / bin / atos está em movimento e será removido de uma versão futura do OS X. Agora está disponível nas ferramentas do desenvolvedor do Xcode para serem chamadas por meio de:xcrun atos

Eu gosto de usar o Textwrangler para identificar erros em uma rejeição binária de upload de aplicativo original. (Os dados da falha serão encontrados na sua conta do itunesConnect.) Usando o método de Sachin acima, copio o original.crash para o TextWrangler e, em seguida, copio o arquivo symbolicatecrash que criei para outro arquivo do TextWrangler. A comparação dos dois arquivos identifica diferenças. O arquivo symbolicatecrash terá diferenças que apontam o arquivo e o número da linha de problemas.

Usamos o Google Crashlytics para supervisionar os logs de falhas, a sensação é muito oportuna e conveniente de usar.

Links do documento ： https://docs.fabric.io/apple/crashlytics/missing-dsyms.html#missing-dsyms

Tudo sobre o dSYMs Fabric ausente inclui uma ferramenta para carregar automaticamente o dSYM do seu projeto. A ferramenta é executada por meio do script / run, que é adicionado à sua fase de criação do script de execução durante o processo de integração. Entretanto, pode haver certas situações, quando os uploads do dSYM falham devido a configurações exclusivas do projeto ou se você estiver usando o Bitcode no seu aplicativo. Quando um upload falha, o Crashlytics não pode simbolizar e exibir falhas, e um alerta "Missing dSYM" aparecerá no painel do Fabric.

Os dSYMs ausentes podem ser carregados manualmente seguindo as etapas descritas abaixo.

Nota: Como alternativa à ferramenta de upload dSYM automatizada, o Fabric fornece uma ferramenta de linha de comando (símbolos de upload)) que pode ser configurada manualmente para executar como parte do processo de construção do seu projeto. Consulte a seção de símbolos de upload abaixo para obter instruções de configuração.

...