Simboleggia i rapporti sugli arresti anomali dell'app per iPhone

Sto cercando di simboleggiare i rapporti sugli arresti anomali della mia app per iPhone.

Ho recuperato i rapporti sugli arresti anomali da iTunes Connect. Ho il file binario dell'applicazione che ho inviato all'App Store e ho il file dSYM che è stato generato come parte della build.

Ho tutti questi file insieme in un'unica directory indicizzata da Spotlight.

E adesso?

Ho provato a invocare:

symbolicatecrash crashreport.crash myApp.app.dSYM

e genera solo lo stesso testo presente nel rapporto sugli arresti anomali, non simbolizzato.

Sto facendo qualcosa di sbagliato?

I passaggi per analizzare il rapporto sugli arresti anomali da Apple:

1. Copia il file .app di rilascio che è stato trasferito nell'app store, il file .dSYM che è stato creato al momento del rilascio e il rapporto di arresto anomalo viene ricevuto da APPLE in una CARTELLA .

2. Apri l'applicazione terminale e vai alla cartella creata sopra (usando il cdcomando)

3. Corri atos -arch armv7 -o APPNAME.app/APPNAME MEMORY_LOCATION_OF_CRASH. La posizione della memoria dovrebbe essere quella in cui l'app si è arrestata in modo anomalo come da report.

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

Ciò mostrerebbe la riga esatta, il nome del metodo che ha provocato l'arresto anomalo.

Ex: [classname functionName:]; -510

Simbolizzante IPA

se utilizziamo IPA per simbolizzare, basta rinominare l'estensione .ipa con .zip, estrarla per ottenere una cartella di payload che contenga un'app. In questo caso non è necessario il file .dSYM.

Nota

Questo può funzionare solo se il file binario dell'app non ha simboli rimossi. Per impostazione predefinita, le build di rilascio hanno rimosso i simboli. Possiamo cambiarlo nelle impostazioni di compilazione del progetto "Rimuovi simboli di debug durante la copia" su NO.

Maggiori dettagli vedi questo post

Dopo aver letto tutte queste risposte qui al fine di simboleggiare un registro degli arresti anomali (e alla fine riuscito), penso che manchino alcuni punti che sono davvero importanti per determinare perché l'invocazione di Symbolicatecrash non produce un output simbolizzato.

Ci sono 3 risorse che devono adattarsi insieme quando simbolizza un registro degli arresti anomali:

1. Il file di registro degli arresti anomali stesso (ovvero example.crash), esportato dall'organizzatore XCode o ricevuto da iTunes Connect.
2. Il .apppacchetto (ovvero example.app) che contiene esso stesso il file binario dell'app appartenente al registro degli arresti anomali. Se si dispone di un .ipapacchetto (ovvero example.ipa), è possibile estrarre il .apppacchetto decomprimendo il .ipapacchetto (ovvero unzip example.ipa). Successivamente il .apppacchetto risiede nella Payload/cartella estratta .
3. Il .dSYMpacchetto contenente i simboli di debug (ovvero example.app.dSYM)

Prima di iniziare la simbolizzazione, dovresti controllare se tutti questi artefatti corrispondono, il che significa che il registro degli arresti anomali appartiene al binario che hai e che i simboli di debug sono quelli prodotti durante la compilazione di quel binario.

Ogni binario è indicato da un UUID che può essere visto nel file di registro degli arresti anomali:

...
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
...

In questo estratto il registro degli arresti anomali appartiene a un'immagine binaria dell'app denominata esempio.app/esempio con UUID aa5e633efda8346cab92b01320043dc3.

Puoi controllare l'UUID del pacchetto binario che hai con dwarfdump:

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

Successivamente dovresti controllare se i simboli di debug che hai appartengono anche a quel binario:

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

In questo esempio tutte le risorse si incastrano e dovresti essere in grado di simboleggiare la tua stack stack.

Procedendo alla symbolicatecrashsceneggiatura:

In Xcode 8.3 dovresti essere in grado di invocare lo script tramite

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

Se non è presente, è possibile eseguire un find . -name symbolicatecrashnella directory Xcode.app per trovarlo.

Come puoi vedere non ci sono più parametri forniti. Quindi lo script deve trovare i simboli binari e di debug dell'applicazione eseguendo una ricerca Spotlight. Cerca i simboli di debug con un indice specifico chiamato com_apple_xcode_dsym_uuids. Puoi fare questa ricerca da solo:

mdfind 'com_apple_xcode_dsym_uuids = *'

resp.

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

La prima chiamata Spotlight ti dà tutti i pacchetti indicizzati dSYM e la seconda ti dà i .dSYMpacchetti con un UUID specifico. Se Spotlight non trova il tuo .dSYMpacchetto symbolicatecrash, non lo sarà nemmeno. Se fai tutte queste cose, ad esempio in una sottocartella dei tuoi ~/Desktopriflettori, dovresti riuscire a trovare tutto.

Se symbolicatecrashtrova il tuo .dSYMpacchetto, dovrebbe esserci una riga come la seguente in symbolicate.log:

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

Per trovare il tuo .apppacchetto viene invocata una ricerca spotlight come la seguente symbolicatecrash:

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

Se symbolicatecrashtrova il tuo .apppacchetto, dovrebbe esserci il seguente estratto in symbolicate.log:

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

Se tutte queste risorse vengono trovate da symbolicatecrashesso dovrebbe stampare la versione simbolizzata del registro degli arresti anomali.

Altrimenti puoi trasferire direttamente i tuoi file dSYM e .app.

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: il backtrace simbolizzato verrà inviato al terminale, no symbolicate.log.

Con l'ultima versione di Xcode (3.2.2), puoi trascinare e rilasciare tutti i rapporti sugli arresti anomali nella sezione Log dispositivo di Xcode Organizer e questi verranno automaticamente simbolizzati per te. Penso che funzioni meglio se hai creato quella versione dell'app usando Build & Archive (anche parte di Xcode 3.2.2)

L'ho fatto con successo, usando i seguenti passi.

Passaggio 1: crea una cartella sul desktop, la assegno a "CrashReport" e inserisco tre file ("MYApp.app", "MyApp.app.dSYM", "MYApp_2013-07-18.crash").

Passaggio 2: Apri Finder e vai su Applicazioni, dove troverai l'applicazione Xcode, fai clic destro su questo e fai clic su "Mostra contenuto pacchetto", dopo questo segui questo semplice percorso. "Contenuti-> Sviluppatore-> Piattaforme-> iPhoneOS.platform-> Sviluppatore-> Libreria-> PrivateFrameworks- > DTDeviceKit.framework -> Versioni-> A-> Risorse"

O

"Contenuti-> Sviluppatore-> Piattaforme-> iPhoneOS.platform-> Sviluppatore-> Libreria-> PrivateFrameworks- > DTDeviceKitBase.framework -> Versioni-> A-> Risorse"

O

Per Xcode 6 e versioni successive il percorso è Applicazioni / Xcode.app / Sommario / SharedFrameworks / DTDeviceKitBase.framework / Versioni / A / Risorse

Dove trovi il file "symbolicatecrash", copialo e incollalo nella cartella "CrashReport".

Passaggio 3: avviare il terminale, eseguire questi 3 comandi

1. cd / Users / mac38 / Desktop / CrashReport e premere il pulsante Enter

2. export DEVELOPER_DIR = "/ Applicazioni / Xcode.app / Sommario / Sviluppatore" e premere Invio

3. ./symbolicatecrash -A -v MYApp_2013-07-18.crash MyApp.app.dSYM e premi Invio Ora è Fatto .. (NOTA: le versioni intorno alla 6.4 o successive non hanno l'opzione -A - lasciala fuori).

I passaggi per simboleggiare automaticamente un rapporto di arresto anomalo utilizzando XCode:

AGGIORNATO PER XCODE 9

1. Collega qualsiasi dispositivo iOS al tuo Mac (sì, uno fisico, sì, lo so che è stupido)

2. Scegli "Dispositivi" dal menu "Finestra"

3. Fare clic sul dispositivo a sinistra e VISUALIZZA REGISTRO DISPOSITIVO a destra

4. Aspettare. Potrebbe volerci un minuto per presentarsi. Forse lo sto facendoCommand-A allora Deletesarà accelerare l'operazione.

5. Fase critica non documentata: rinominare la segnalazione di crash che avete ottenuto da iTunesConnect da .txtestensione a .crashestensione

6. Trascina il rapporto di arresto anomalo in quell'area a sinistra

E quindi Xcode simboleggerà il rapporto sugli arresti anomali e visualizzerà i risultati.

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

Uso Airbrake nelle mie app, il che fa un buon lavoro di registrazione remota degli errori.

Ecco come li simbolizzo con atos se il backtrace ne ha bisogno:

1. In Xcode (4.2) vai all'organizzatore, fai clic destro sull'archivio da cui è stato generato il file .ipa.

2. In Terminale, ad esempio , cd in xcarchiveMyCoolApp 10-27-11 1.30 PM.xcarchive

3. Inserisci quanto segue atos -arch armv7 -o 'MyCoolApp.app'/'MyCoolApp' (non dimenticare le virgolette singole)

4. Non includo il mio simbolo in quella chiamata. Quello che ottieni è un cursore a blocchi su una riga vuota.

5. Quindi copio / incollo il mio codice simbolo sul cursore del blocco e premo invio. Vedrai qualcosa del tipo:

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

6. Sei tornato a un cursore a blocchi e puoi incollare altri simboli.

Essere in grado di passare attraverso il backtrace di un elemento senza reinserire il primo bit è un bel risparmio di tempo.

Godere!

Ho anche inserito dsym, bundle di app e registro degli arresti anomali nella stessa directory prima di eseguire l'arresto anomalo simbolico

Quindi uso questa funzione definita nel mio .profile per semplificare l'esecuzione di symbolicatecrash:

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

Gli argomenti aggiunti possono aiutarti.

Puoi verificare che Spotlight "veda" i tuoi file dysm eseguendo il comando:

mdfind 'com_apple_xcode_dsym_uuids = *'

Cerca il dsym che hai nella tua directory.

NOTA: a partire dall'ultimo Xcode, non esiste più una directory per sviluppatori. Puoi trovare questa utility qui:

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

Solo una risposta semplice e aggiornata per xcode 6.1.1.

PASSI

1.Xcode> Finestra> Dispositivi.

2. Selezionare un dispositivo da un elenco di dispositivi nella sezione DISPOSITIVI.

3. Selezionare Visualizza registri dispositivo.

4.Nella sezione Tutti i registri è possibile trascinare direttamente drop.crash

5.Xcode simboleggia automaticamente il rapporto di arresto anomalo per te.

6.È possibile trovare il rapporto sugli arresti anomali simbolizzato abbinando la sua data / ora con la data / ora menzionata nel rapporto sugli arresti anomali.

Anche se avevo sviluppato app da alcuni anni, questa era la prima volta che eseguivo il debug di un file binario e mi sentivo come un NOOB completo per capire dove fossero tutti i file, ovvero dove sono * .app * .dSYM e i registri degli arresti anomali? Ho dovuto leggere più post per capirlo. L'immagine vale più di mille parole e spero che questo post aiuti chiunque altro in futuro.

1- Prima vai su itunesconnect e scarica i log degli arresti anomali. NOTA: nella maggior parte dei casi è possibile che venga visualizzato qualcosa del tipo "Sono stati inviati troppi rapporti per la visualizzazione di un rapporto". Fondamentalmente non abbastanza utenti hanno inviato i rapporti del registro degli arresti anomali ad Apple, nel qual caso a quel punto non puoi fare molto.

2- Ora se non hai modificato il codice da quando lo hai inviato ad Apple, allora avvia Xcode per quel progetto e fai nuovamente Product -> Archive. Altrimenti basta trovare l'ultimo binario inviato e fare clic con il tasto destro su di esso.

In Xcode 4.2.1, apri Organizer , quindi vai a Library / Device Logs e trascina il tuo file .crash nell'elenco dei log degli arresti anomali. Sarà simbolizzato per te dopo pochi secondi.

Nota che devi usare la stessa istanza di Xcode su cui è stata archiviata la build originale (ovvero l'archivio per la tua build deve esistere in Organizer ).

Utilizzando Xcode 4, l'attività è ancora più semplice:

• organizzatore aperto ,
• fai clic su Libreria | Log dispositivo nella colonna di sinistra
• fai clic sul pulsante " Importa " nella parte inferiore dello schermo ...

e voilà. Il file di registro viene importato e simbolizzato automaticamente per te. Fornito Archiviato la build utilizzando Xcode -> Prodotto -> Archivia prima.

Il magico Xcode Organizer non è così magico nel simbolizzare la mia app. Non ho ricevuto alcun simbolo per i rapporti sugli arresti anomali che sono tornato da Apple da un invio di app non riuscito.

Ho provato a utilizzare la riga di comando, inserendo il rapporto di arresto anomalo nella stessa cartella del file .app (che ho inviato al negozio) e del file .dSYM:

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

Ciò forniva solo simboli per la mia app e non il codice base della fondazione, ma era meglio del dump del numero che mi stava organizzando Organizer ed era abbastanza per me trovare e correggere il crash che aveva la mia app. Se qualcuno sa come estenderlo per ottenere i simboli della Fondazione, sarebbe apprezzato.

Nel mio caso, stavo trascinando i rapporti sugli arresti anomali direttamente da Mail all'Organizer. Per qualche motivo, ciò ha impedito che i rapporti sugli arresti anomali fossero simbolizzati (mi piacerebbe sapere perché).

Copiare prima i rapporti sugli arresti anomali sul desktop e quindi trascinarli da lì sull'Organizer li ha simbolizzati correttamente.

Caso molto specifico, lo so. Ma ho pensato di condividere per ogni evenienza.

Ecco un altro problema che ho con symbolicatecrash: non funzionerà con le App che hanno spazi nel loro bundle (ad esempio "Test App.app"). Nota Non penso che tu possa avere spazi nel loro nome durante l'invio, quindi dovresti rimuoverli comunque, ma se hai già degli arresti anomali che devono essere analizzati, patch symbolicatecrash (4.3 GM) come tale:

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\"";

Per quelli che usano Airbrake, c'è una solida risposta sopra ma non funzionerebbe per me senza modificare:

Funziona con alcuni indirizzi di memoria ma non con altri, non so perché ...

• Crea una nuova directory sul desktop o ovunque
• Trova l'archivio in questione nell'organizzatore Xcode
• Tocca due volte per visualizzare nel Finder
• Tocca due volte per mostrare i contenuti del pacchetto
• Copia il file .dSYM e il file .app nella nuova dir
• cd in nuova dir
• Esegui questo comando: atos -arch armv7 -o 'Vimeo.app' / 'Vimeo'
• Il terminale entrerà in una mossa interattiva
• Incolla l'indirizzo di memoria e premi invio, genererà il nome del metodo e il numero di riga
• In alternativa, immettere questo comando: atos -arch armv7 -o 'Vimeo.app' / 'Vimeo' Per ottenere informazioni per un solo indirizzo

La combinazione che ha funzionato per me è stata:

1. Copia il file dSYM nella directory in cui si trovava il rapporto sull'arresto anomalo
2. Decomprimi il file ipa che contiene l'app ('decomprimi MyApp.ipa')
3. Copia il file binario dell'applicazione dal payload esploso risultante nella stessa cartella del rapporto di arresto anomalo e del file dei simboli (qualcosa come "MyApp.app/MyApp")
4. Importa o simboleggia nuovamente il rapporto sugli arresti anomali dall'organizzatore di Xcode

Usando atos non sono stato in grado di risolvere le informazioni corrette sul simbolo con gli indirizzi e gli offset presenti nel rapporto sugli arresti anomali. Quando l'ho fatto, vedo qualcosa di più significativo e sembra essere una traccia dello stack legittima.

Ho dovuto fare un sacco di hacking dello script symbolicatecrash per farlo funzionare correttamente.

Per quanto ne so, symbolicatecrash in questo momento richiede che .app sia nella stessa directory di .dsym. Utilizzerà .dsym per localizzare .app, ma non utilizzerà dsym per trovare i simboli.

Dovresti fare una copia del tuo symbolicatecrash prima di provare queste patch che lo faranno apparire nel dsym:

Intorno alla linea 212 nella funzione getSymbolPathFor_dsymUuid

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

Intorno alla linea 265 nella funzione matchUUID

265             return 1;

Questo è semplice, dopo aver cercato molto ho trovato dei passaggi chiari per simboleggiare l'intero file di registro degli arresti anomali.

• copia i file .app, crash_report e DSYM in una cartella.
• collegare il dispositivo con xcode
• Quindi vai alla finestra -> seleziona i dispositivi -> visualizza i registri dei dispositivi
• Quindi selezionare questo dispositivo, eliminare tutti i registri.
• trascina e rilascia l'arresto anomalo nella sezione del registro del dispositivo. simboleggia automaticamente l'incidente. basta fare clic destro sul rapporto ed esportarlo.

buona programmazione,
Riyaz

Preferisco uno script che simboleggi tutti i miei registri degli arresti anomali.

presupposti

Crea una cartella e metti lì 4 cose:

1. symbolicatecrash script perl - ci sono molte risposte SO che indicano la sua posizione

2. L'archivio della build che corrisponde agli arresti anomali (da Xcode Organizer. Semplice come Show in Findere copia) [Non sono sicuro che sia necessario]

3. Tutti i xccrashpointpacchetti - (da Xcode Organizer. Show in Finder, È possibile copiare tutti i pacchetti nella directory o il singolo xccrashpoint che si desidera simboleggiare)

4. Aggiungi quel breve script alla directory:

   #!/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 ""

Il copione

Quando esegui lo script, otterrai 2 directory.

1. allCrashes- tutti gli arresti anomali di tutti xccrashpointsaranno lì.

2. symboledCrashes - lo stesso si blocca ma ora con tutti i simboli.

3. NON è necessario pulire la directory da vecchi arresti anomali prima di eseguire lo script. pulirà automaticamente. in bocca al lupo!

Ho scoperto che la maggior parte delle alternative proposte non ha funzionato nell'ultimo XCode (testato con Xcode 10). Ad esempio, non ho avuto fortuna trascinando i log .crash in Xcode -> Organizer -> Log dei dispositivi -view.

Consiglio di utilizzare lo strumento Symbolicator https://github.com/agentsim/Symbolicator

• Git clone Symbolicator repository e compilare ed eseguire con Xcode
• Copia il file .crash (file ascii, con traccia dello stack in attesa del file) e .xarchive del rilascio anomalo nella stessa cartella temporanea
• Trascina e rilascia il file .crash sull'icona Symbolicator nel Dock
• In 5-30 secondi il file crash simbolizzato viene prodotto nella stessa cartella di .crash e .xarchive

Per simboleggiare gli arresti anomali, Spotlight deve essere in grado di trovare il file .dSYM che è stato generato contemporaneamente al file binario inviato ad Apple. Poiché contiene le informazioni sul simbolo, sarai sfortunato se non è disponibile.

Sono diventato un po 'scontroso sul fatto che nulla qui sembra "funzionare", quindi ho fatto qualche indagine e il risultato è:

Impostazione: back-end QuincyKit che riceve i report. Non è stata istituita alcuna simbolizzazione poiché non riuscivo nemmeno a capire cosa stessero suggerendo di fare per farlo funzionare.

La correzione: scarica i rapporti sugli arresti anomali dal server online. Si chiamano 'crash' e per impostazione predefinita vanno nella cartella ~ / Download /. Tenendo presente ciò, questo script "farà la cosa giusta" e i rapporti sugli arresti anomali andranno in Xcode (Organizer, registri dei dispositivi) e verrà eseguita la simbolizzazione.

Il copione:

#!/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"

Le cose possono essere automatizzate in cui è possibile trascinare e rilasciare Xcode Organizer facendo due cose se si utilizza QuincyKit / PLCR.

Innanzitutto, devi modificare lo script remoto admin / actionapi.php ~ linea 202. Non sembra che il timestamp sia corretto, quindi il file finisce con il nome 'crash' che Xcode non riconosce (vuole qualcosa punto crash):

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

In secondo luogo, nella parte iOS in QuincyKit BWCrashReportTextFormatter.m ~ linea 176, cambia @"[TODO]"in @"TODO"per aggirare i personaggi cattivi.

atos è deprecato, quindi se si esegue OSX 10.9 o versione successiva potrebbe essere necessario eseguirlo

xcrun atos

Avvertenza: / usr / bin / atos si sta muovendo e verrà rimosso da una futura versione di OS X. Ora è disponibile negli strumenti per sviluppatori Xcode da invocare tramite:xcrun atos

Mi piace usare Textwrangler per individuare errori in un rifiuto binario del caricamento di un'app originale. (I dati del crash si troveranno nel tuo account itunesConnect.) Utilizzando il metodo di Sachin sopra copio il file original.crash in TextWrangler, quindi copio il file symbolicatecrash che ho creato in un altro file TextWrangler. Il confronto tra i due file individua le differenze. Il file symbolicatecrash presenterà differenze che indicano il file e il numero di riga dei problemi.

Usiamo Google Crashlytics per controllare i registri degli arresti anomali, la sensazione è molto tempestiva e comoda da usare.

Link ai documenti ： https://docs.fabric.io/apple/crashlytics/missing-dsyms.html#missing-dsyms

Tutto su Missing dSYMs Fabric include uno strumento per caricare automaticamente il dSYM del tuo progetto. Lo strumento viene eseguito tramite lo script / run, che viene aggiunto alla fase di esecuzione dello script Run durante il processo di onboarding. Tuttavia, possono verificarsi alcune situazioni in cui i caricamenti di dSYM non riescono a causa di configurazioni di progetto univoche o se si utilizza Bitcode nella propria app. Quando un caricamento fallisce, Crashlytics non è in grado di simboleggiare e visualizzare arresti anomali e un avviso "Missing dSYM" apparirà sulla dashboard di Fabric.

I dSYM mancanti possono essere caricati manualmente seguendo i passaggi descritti di seguito.

Nota: in alternativa allo strumento di caricamento automatico dSYM, Fabric fornisce uno strumento da riga di comando (upload-simboli) che può essere configurato manualmente per essere eseguito come parte del processo di creazione del progetto. Vedere la sezione dei simboli di caricamento di seguito per le istruzioni di configurazione.

...