Symboles des rapports de crash de l'application iPhone

433

Je cherche à symboliser les rapports de plantage de mon application iPhone.

J'ai récupéré les rapports d'erreur sur iTunes Connect. J'ai le fichier binaire d'application que j'ai soumis à l'App Store et j'ai le fichier dSYM qui a été généré dans le cadre de la construction.

J'ai tous ces fichiers ensemble dans un seul répertoire indexé par Spotlight.

Et maintenant?

J'ai essayé d'invoquer:

symbolicatecrash crashreport.crash myApp.app.dSYM

et il sort juste le même texte qui est dans le rapport de plantage pour commencer, non symbolisé.

Est-ce que je fais quelque chose de mal?

Jasarien
la source
3
Vous pouvez également voir ma réponse sur le SDK iPhone: Où se trouve symbolicatecrash.sh? . Je liste où trouver la symbolicatecrashcommande, comment l'utiliser et comment trouver le fichier dSYM nécessaire pour effectuer la symbolisation.
Sam
6
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash
logancautrell
5
J'ai créé un script qui peut vous aider: github.com/amleszk/scripts/blob/master/…
amleszk
1
Si quelqu'un se demande où pouvez-vous obtenir * .app, * .dSYM et les journaux de plantage pour être avec alors regardez ma réponse ci-dessous.
Sam B
3
Vous pouvez vous référer à ceci: medium.com/@Mrugraj/crash-re-symbolication-5c28d3a3a883
Mrug

Réponses:

689

Étapes pour analyser le rapport de plantage d'Apple:

  1. Copiez le fichier .app de version qui a été poussé vers l'appstore, le fichier .dSYM qui a été créé au moment de la publication et le rapport de plantage reçu d'APPLE dans un DOSSIER .

  2. Ouvrez l'application terminal et accédez au dossier créé ci-dessus (à l'aide de la cdcommande)

  3. Courez atos -arch armv7 -o APPNAME.app/APPNAME MEMORY_LOCATION_OF_CRASH. L'emplacement de la mémoire doit être celui auquel l'application s'est bloquée conformément au rapport.

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

Cela vous montrera la ligne exacte, le nom de la méthode qui a entraîné un crash.

Ex: [classname functionName:]; -510

IPA symbolisant

si nous utilisons IPA pour symboliser - renommez simplement l'extension .ipa avec .zip, extrayez-le alors nous pouvons obtenir un dossier de charge utile qui contient une application. Dans ce cas, nous n'avons pas besoin du fichier .dSYM.

Remarque

Cela ne peut fonctionner que si le binaire de l'application n'a pas de symboles supprimés. Par défaut, les versions libèrent les symboles. Nous pouvons le changer dans les paramètres de construction du projet "Supprimer les symboles de débogage pendant la copie" sur NON.

Plus de détails voir cet article

Naveen Shan
la source
12
Juste une astuce pour répondre à @NaveenShan, un exemple réel ferait cela atos -o myApp.app/Contents/MacOS/myApp 0x0000000100001f2c et vous obtenez -[HUDWindow sizedHUDBackground] (in myApp) + 1197
loretoparisi
3
Quelle adresse utilisez-vous cependant? Les journaux ont deux colonnes d'adresses après chaque fonction, et la seconde a un + et un décalage en quelque sorte. Comme 0x332da010 0x332d9000 + 4112.
Oscar
7
@OscarGoldman La deuxième adresse, par exemple: - Dans 0x332da010 0x332d9000 + 4112. utilisez 0x332d9000.
Naveen Shan
4
De plus, s'il est utilisé sans adresse, il vous permet d'analyser plusieurs emplacements en les soumettant un par un.
Paul Ardeleanu
42
Il y a plusieurs problèmes avec cette réponse: 1. Cela ne peut fonctionner que si le binaire de l'application n'a pas de symboles supprimés. Et les versions par défaut les ont supprimées. 2. Même si les symboles sont disponibles, il ne montrera jamais le numéro de ligne. Seule la symbolisation avec le dSYM fournira cela. 3. Vous ne pouvez pas simplement utiliser l'adresse mémoire indiquée dans la trace de la pile, l'adresse doit être normalisée par rapport à l'adresse mémoire de démarrage dans laquelle l'application est chargée. Plus de détails voir cette réponse: stackoverflow.com/questions/13574933/…
Kerni
173

Après avoir lu toutes ces réponses ici afin de symboliser un journal de plantage (et finalement réussi), je pense qu'il manque quelques points ici qui sont vraiment importants pour déterminer pourquoi l'invocation de symbolicatecrash ne produit pas une sortie symbolisée.

Il y a 3 actifs qui doivent s'imbriquer lors de la symbolisation d'un journal des pannes:

  1. Le fichier journal des plantages lui-même (c'est-à-dire example.crash ), soit exporté de l'organisateur de XCode, soit reçu d'iTunes Connect.
  2. Le .apppackage (c'est-à-dire example.app) qui contient lui-même le binaire d'application appartenant au journal des plantages. Si vous avez un .ipapackage (ie example.ipa), vous pouvez extraire le .apppackage en décompressant le .ipapackage (ie unzip example.ipa). Ensuite, le .apppaquet réside dans le fichier extraitPayload/ dossier .
  3. Le .dSYMpaquet contenant les symboles de débogage (ie example.app.dSYM)

Avant de commencer la symbolisation, vous devez vérifier si tous ces artefacts correspondent, ce qui signifie que le journal des plantages appartient au binaire que vous avez et que les symboles de débogage sont ceux produits lors de la génération de ce binaire.

Chaque binaire est référencé par un UUID qui peut être vu dans le fichier journal des plantages:

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

Dans cet extrait, le journal des plantages appartient à une image binaire d'application nommée example.app/example avec UUID aa5e633efda8346cab92b01320043dc3 .

Vous pouvez vérifier l'UUID du package binaire que vous avez avec dwarfdump:

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

Ensuite, vous devriez vérifier si les symboles de débogage que vous avez appartiennent également à ce binaire:

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

Dans cet exemple, tous les actifs s'assemblent et vous devriez pouvoir symboliser votre stacktrace.

Procéder au symbolicatecrashscript:

Dans Xcode 8.3, vous devriez pouvoir invoquer le script via

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

S'il n'est pas là, vous pouvez exécuter un find . -name symbolicatecrashdans votre répertoire Xcode.app pour le trouver.

Comme vous pouvez le voir, il n'y a plus de paramètres donnés. Le script doit donc trouver les symboles binaires et de débogage de votre application en exécutant une recherche Spotlight. Il recherche les symboles de débogage avec un index spécifique appelé com_apple_xcode_dsym_uuids. Vous pouvez faire cette recherche vous-même:

mdfind 'com_apple_xcode_dsym_uuids = *'

resp.

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

La première invocation Spotlight vous donne tous les packages dSYM indexés et la seconde vous donne les .dSYMpackages avec un UUID spécifique. Si Spotlight ne trouve pas votre .dSYMcolis, il symbolicatecrashne le fera pas non plus. Si vous faites tout cela par exemple dans un sous-dossier de votre~/Desktop projecteur, devriez pouvoir tout trouver.

Si symbolicatecrashtrouve votre .dSYMcolis, il devrait y avoir une ligne comme celle-ci dans symbolicate.log:

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

Pour trouver votre .apppackage, une recherche Spotlight comme celle-ci est invoquée par symbolicatecrash:

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

Si symbolicatecrashtrouve votre .apppaquet, il devrait y avoir l'extrait suivant dans symbolicate.log:

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

Si toutes ces ressources sont trouvées, symbolicatecrashil devrait imprimer la version symbolisée de votre journal des plantages.

Sinon, vous pouvez directement transmettre vos fichiers dSYM et .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

Remarque: La trace symbolisée sera sortie vers le terminal, non symbolicate.log.

Andreas Klöber
la source
je peux trouver tous les fichiers mais j'obtiens ceci, et aucune sortie symboliséeNo crash report version in testlog.crash at /usr/bin/symbolicatecrash line 921.
jere
1
C'était vraiment utile! Dans mon cas, le fichier .app a un nom différent de celui de l'exécutable (je ne sais pas pourquoi mais il est construit de cette façon par Xcode). Après avoir renommé le fichier .app dans l'archive XCode, la symbolisation a fonctionné.
Hrissan
29
Ceci est une excellente explication et devrait être la première réponse OMI, merci. Notez que vous pouvez avoir à définir votre DEVELOPER_DIRvariable d'environnement si le script se plaint comme ceci: export DEVELOPER_DIR=`xcode-select --print-path` . J'ai ajouté cette ligne à mon ~/.bash_profile. Voir stackoverflow.com/q/11682789/350761
Eliot
1
Notez que pour Xcode 5, ce qui a déménagé à: <PATH_TO_Xcode.app> /Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/Current/Resources/symbolicatecrash
Eliot
1
symbolicate crash a également plusieurs options utiles. <SYMBOL_PATH> Additional search paths in which to search for symbol rich binaries -o | --output <OUTPUT_FILE> The symbolicated log will be written to OUTPUT_FILE. Defaults to "-" (i.e. stdout) if not specified -d | --dsym <DSYM_BUNDLE> Adds additional dSYM that will be consulted if and when a binary's UUID matches (may be specified more than once)
benuuu
115

Avec la dernière version de Xcode (3.2.2), vous pouvez faire glisser et déposer tous les rapports d'erreur dans la section Journaux des périphériques de l'organisateur Xcode et ils seront automatiquement symbolisés pour vous. Je pense que cela fonctionne mieux si vous avez construit cette version de l'application en utilisant Build & Archive (également partie de Xcode 3.2.2)

Alan Rogers
la source
3
Cela ne fonctionne tout simplement pas avec Xcode4, sur une nouvelle installation. Semble être un nouveau bug :(
Adam
1
Je ne sais pas si cela résout le même problème que vous, mais quelqu'un a corrigé le script symbolique github.com/nskboy/symbolicatecrash-fix YMMV :)
Alan Rogers
2
Cette astuce fonctionne avec Xcode 4.2. Placer les crashlogs dans les journaux de périphérique de l'organiseur. Redémarrez l'Organiseur pour obtenir des journaux de plantage symbolisés !!! Merci.
harshit2811
2
Cela n'a pas fonctionné de moi lorsque j'ai importé un fichier d'archive à partir d'un autre ordinateur pour obtenir un journal de plantage. :( Pour cette raison, j'ai dû symboliser manuellement le fichier. Vous pouvez trouver des étapes sur la façon de faire la symbolisation ici: iPhone SDK: Où se trouve symbolicatecrash.sh?
Sam
3
Ne fonctionne pas pour moi avec les rapports d'erreur téléchargés depuis iTunes Connect.
Dmitry
72

J'ai fait cela avec succès, en utilisant les étapes suivantes.

Étape 1: Créez un dossier sur le bureau, je le nomme "CrashReport" et y mets trois fichiers ("MYApp.app", "MyApp.app.dSYM", "MYApp_2013-07-18.crash").

Étape 2: Ouvrez le Finder et allez dans Applications, où vous trouverez l'application Xcode, faites un clic droit dessus et cliquez sur "Afficher le contenu du package", après cela, suivez ce chemin simple. "Contents-> Developer-> Platforms-> iPhoneOS.platform-> Developer-> Library-> PrivateFrameworks-> DTDeviceKit.framework -> Versions-> A-> Resources"

OU

"Contents-> Developer-> Platforms-> iPhoneOS.platform-> Developer-> Library-> PrivateFrameworks-> DTDeviceKitBase.framework -> Versions-> A-> Resources"

OU

Pour Xcode 6 et supérieur, le chemin est Applications / Xcode.app / Contents / SharedFrameworks / DTDeviceKitBase.framework / Versions / A / Resources

Où vous trouvez le fichier "symbolicatecrash", copiez-le et collez-le dans le dossier "CrashReport".

Étape 3: lancez le terminal, exécutez ces 3 Command

  1. cd / Users / mac38 / Desktop / CrashReport et appuyez sur le bouton Entrée

  2. export DEVELOPER_DIR = "/ Applications / Xcode.app / Contents / Developer" et appuyez sur Entrée

  3. ./symbolicatecrash -A -v MYApp_2013-07-18.crash MyApp.app.dSYM et appuyez sur Enter Now its Done. (REMARQUE: les versions autour de 6.4 ou ultérieur n'ont pas l'option -A - laissez-la simplement de côté).
SachinVsSachin
la source
3
pour DTServiceKit, regardez dans Applications / Xcode.app / Contents / SharedFrameworks
Ryan Heitner
3
Merci Merci ... au 9 avril 2015, c'est ce qui a parfaitement fonctionné pour moi. Une chose, c'est que j'ai eu Unknown option: Apour symbolicatecrash, mais le processus a quand même fonctionné
Matt Fiocca
1
J'aimerais pouvoir donner mille points à cette réponse. Il y a tellement de procédures sur ce sujet ... mais c'est celle qui fonctionne au niveau le plus bas, donc ça fonctionne TOUJOURS. C'est pénible à l'arrière de franchir toutes les marches, mais quand tout le reste échoue, cela fait le travail.
Chad Robinson
35

Étapes pour symboliser automatiquement un rapport d'erreur à l'aide de XCode:

MIS À JOUR POUR XCODE 9

  1. Connectez n'importe quel appareil iOS à votre Mac (oui physique, oui je sais que c'est stupide)

  2. Choisissez "Appareils" dans le menu "Fenêtre" entrez la description de l'image ici

  3. Cliquez sur votre appareil à gauche et VOIR LES JOURNAUX DES APPAREILS à droite entrez la description de l'image ici

  4. Attendre. Cela peut prendre une minute pour apparaître. Peut-être que faire Command-Aalors Deleteaccélérera cela.

  5. Étape critique non documentée: renomme le rapport accident que vous avez obtenu de iTunesConnect d'.txtextension à.crashextension

  6. Faites glisser le rapport de crash dans cette zone à gauche entrez la description de l'image ici

Et puis Xcode symbolisera le rapport de plantage et affichera les résultats.

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

William Entriken
la source
1
Il s'agit de la procédure officielle d'Apple. Ça devrait être la réponse.
Giammy
2
Merci, j'ajoute des photos maintenant. Également inclus l'étape SUPER NON-CONCUMENTÉE. J'ai pensé à faire un git de texte rouge et à le coller ici pour qu'il se démarque vraiment. Puis j'ai arrêté de penser à ça.
William Entriken
1
Je vous remercie! Aucune des autres réponses ne dit réellement que l'appareil que vous utilisez n'a pas besoin d'être l'appareil (ou même le type d'appareil) sur lequel le crash s'est produit.
galactikuh
Petite note, car pour moi ça ne re-symboliserait pas. J'ai également dû ouvrir l'Organiseur, cliquer sur la construction dans Archives, cliquer sur Télécharger les symboles de débogage. Ensuite, je pouvais re-symboliser dans la vue du journal de l'appareil. Il s'agissait d'un journal des plantages téléchargé depuis Apple après un examen rejeté.
gregthegeek
28

J'utilise Airbrake dans mes applications, ce qui fait un assez bon travail de journalisation des erreurs à distance.

Voici comment je les symbolise avec atos si la trace en a besoin:

  1. Dans Xcode (4.2), accédez à l'organisateur, cliquez avec le bouton droit sur l'archive à partir de laquelle le fichier .ipa a été généré.

  2. Dans Terminal, cd dans le xcarchive par exempleMyCoolApp 10-27-11 1.30 PM.xcarchive

  3. Entrez les informations suivantes atos -arch armv7 -o 'MyCoolApp.app'/'MyCoolApp' (n'oubliez pas les guillemets simples)

  4. Je n'inclus pas mon symbole dans cet appel. Ce que vous obtenez est un curseur de bloc sur une ligne vide.

  5. Ensuite, je copie / colle mon code de symbole à ce curseur de bloc et appuyez sur Entrée. Vous verrez quelque chose comme:

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

  6. Vous revenez à un curseur de bloc et vous pouvez coller d'autres symboles.

Être capable de parcourir votre backtrace un élément sans ressaisir le premier bit est un bon gain de temps.

Prendre plaisir!

averydev
la source
28

J'ai également mis dsym, le bundle d'application et le journal des plantages ensemble dans le même répertoire avant d'exécuter le crash symbolique

Ensuite, j'utilise cette fonction définie dans mon .profile pour simplifier l'exécution de symbolicatecrash:

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

Les arguments qui y sont ajoutés peuvent vous aider.

Vous pouvez vérifier que Spotlight "voit" vos fichiers Dysm en exécutant la commande:

mdfind 'com_apple_xcode_dsym_uuids = *'

Recherchez le dsym que vous avez dans votre répertoire.

REMARQUE: Depuis le dernier Xcode, il n'y a plus de répertoire développeur. Vous pouvez trouver cet utilitaire ici:

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

Kendall Helmstetter Gelner
la source
1
J'ai regardé la sortie mdfind, et le fichier dSYM peut certainement être vu sous les projecteurs. Cependant, le script symbolicatecrash ne produit toujours rien de différent du rapport de panne lui-même. Même en utilisant les arguments que vous avez fournis.
Jasarien
Le script devrait produire un texte d'avertissement au début s'il ne trouve pas le dsym - pouvez-vous le rechercher et voir ce qu'il dit?
Kendall Helmstetter Gelner
Essayez également d'ajouter "." après la commande, il s'agirait donc de "symbolicatecrash -A -v MyApp.crashlog". . Cela l'oblige à regarder dans le répertoire courant s'il ne le fait pas déjà.
Kendall Helmstetter Gelner
Signification "Impossible d'exécuter" / usr / bin / xcode-select ": Aucun fichier ou répertoire de ce type sur /Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Plug-ins/iPhoneRemoteDevice.xcodeplugin/Contents/Resources/ ligne symbolique 49. "
bpapa
Oups, apparemment, il y a une autre question SO pour ce stackoverflow.com/questions/1859852/…
bpapa
21

Juste une réponse simple et mise à jour pour xcode 6.1.1.

PAS

1.Xcode> Fenêtre> Périphériques.

2.Sélectionnez un appareil dans une liste d'appareils sous la section APPAREILS.

3.Sélectionnez Afficher les journaux du périphérique.

4.Dans la section Tous les journaux, vous pouvez directement faire glisser le rapport.

5.Xcode symbolisera automatiquement le rapport de plantage pour vous.

6.Vous pouvez trouver le rapport d'erreur symbolisé en faisant correspondre sa date / heure avec la date / heure mentionnée dans votre rapport d'erreur.

Aditya Aggarwal
la source
3
Les rapports de plantage que j'ai téléchargés sur Apple Resolution Center ont généralement l'extension .txt. N'oubliez pas de les renommer en .crash, sinon les journaux de périphérique peuvent refuser de les ajouter. Fonctionne bien pour mon XCode 6.3.1 actuel
Tony
3
Il s'agit de la procédure officielle d'Apple. Ça devrait être la réponse. Lien Apple: Note technique TN2151: Comprendre et analyser les rapports de
plantage des
Comment faire si le crash venait d'Apple / iTunesConnect? En d'autres termes, nous ne savons pas réellement ou n'avons pas l'appareil sur lequel le crash s'est produit?
galactikuh
14

Même si je développais des applications depuis quelques années maintenant, c'était la première fois que je déboguais un binaire et je me sentais comme un NOOB complet pour savoir où étaient tous les fichiers, c'est-à-dire où se trouve * .app * .dSYM et les journaux de plantage? J'ai dû lire plusieurs articles pour le comprendre. L'image vaut mille mots et j'espère que ce message aidera quelqu'un d'autre à l'avenir.

1- Allez d'abord sur itunesconnect et téléchargez vos journaux de plantage. Remarque: dans la plupart des cas, vous pouvez obtenir quelque chose comme «trop peu de rapports ont été soumis pour qu'un rapport soit affiché». Fondamentalement, pas assez d'utilisateurs ont soumis des rapports de journal des pannes à Apple, auquel cas vous ne pouvez pas faire grand chose à ce stade.

entrez la description de l'image ici

entrez la description de l'image ici

2- Maintenant, si vous n'avez pas changé votre code depuis que vous l'avez soumis à Apple, lancez Xcode pour ce projet et refaites Product -> Archive. Sinon, trouvez simplement votre dernier fichier binaire soumis et faites un clic droit dessus.

entrez la description de l'image ici

entrez la description de l'image ici

entrez la description de l'image ici

entrez la description de l'image ici

Sam B
la source
8

Dans Xcode 4.2.1, ouvrez l' Organiseur , puis accédez à Journaux de la bibliothèque / du périphérique et faites glisser votre fichier .crash dans la liste des journaux de plantage. Il vous sera symbolisé après quelques secondes.

Notez que vous devez utiliser la même instance de Xcode sur laquelle la version d'origine a été archivée (c'est-à-dire que l'archive de votre version doit exister dans l' Organiseur ).

cberkley
la source
8

Avec Xcode 4, la tâche est encore plus simple:

  • organisateur ouvert ,
  • cliquez sur Bibliothèque | Journal de l' appareil dans la colonne de gauche
  • cliquez sur le bouton " Importer " en bas de l'écran ...

et voilà. Le fichier journal est importé et symbolisé automatiquement pour vous. À condition que vous ayez archivé la version en utilisant Xcode -> Produit -> Archiver en premier.

Sébastien Stormacq
la source
1
Assez étrange, l'importation n'a aucun effet. Mettre .app, .dSYM et .crash puis exécuter symbolicatecrash sur le fichier .crash (sans aucun argument supplémentaire) a bien fonctionné (XCode 4)
Russe
7

L'organisateur magique de Xcode n'est pas magique pour symboliser mon application. Je n'ai reçu aucun symbole pour les rapports d'erreur que j'ai reçus d'Apple suite à l'échec de la soumission d'une application.

J'ai essayé d'utiliser la ligne de commande, en mettant le rapport de plantage dans le même dossier que le fichier .app (que j'ai soumis au magasin) et le fichier .dSYM:

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

Cela ne fournissait que des symboles pour mon application et non le code de base, mais c'était mieux que le numéro de vidage que l'organisateur me donne et me suffisait pour trouver et corriger le plantage de mon application. Si quelqu'un sait comment étendre cela pour obtenir des symboles de la Fondation, ce serait apprécié.

AndrewS
la source
Pour Core Foundation dSYM, un gars (peut-être chinois) avait téléchargé le dSYM sur son lecteur google partagé, il suffit de le télécharger et de le jeter dans le dossier "appareils pris en charge" et cela sera résolu. github.com/Zuikyo/iOS-System-Symbols
harunaga
6

Dans mon cas, je faisais glisser les rapports de plantage directement de Mail vers l'organisateur. Pour une raison quelconque, cela a empêché les rapports de plantage d'être symbolisés (j'aimerais savoir pourquoi).

Copier d'abord les rapports de plantage sur le bureau, puis les faire glisser de là vers l'Organiseur les a symbolisés correctement.

Cas très précis, je sais. Mais pensais que je partagerais juste au cas où.

samvermette
la source
J'imagine que cela peut avoir quelque chose à voir avec les projecteurs. Y a-t-il une chance que l'emplacement où l'organisateur conserve vos journaux ne soit pas indexé par Spotlight?
Jasarien
4

Voici un autre problème que j'ai avec symbolicatecrash - cela ne fonctionnera pas avec les applications qui ont des espaces dans leur bundle (c'est-à-dire 'Test App.app'). Remarque Je ne pense pas que vous puissiez avoir des espaces dans leur nom lors de la soumission, vous devez donc les supprimer de toute façon, mais si vous avez déjà des plantages qui nécessitent une analyse, corrigez symbolicatecrash (4.3 GM) en tant que tel:

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\"";
Alastair Stuart
la source
Pour ce que ça vaut, j'ai rempli un rdar à ce sujet et c'est corrigé dans [expurgé]
Alastair Stuart
4

Pour ceux qui utilisent Airbrake, il y a une réponse solide ci-dessus, mais cela ne fonctionnerait pas pour moi sans peaufiner:

Fonctionne pour certaines adresses mémoire mais pas pour d'autres, je ne sais pas pourquoi ...

  • Créez un nouveau répertoire sur le bureau ou n'importe où
  • Rechercher l'archive en question dans l'organisateur Xcode
  • Appuyez deux fois pour révéler dans le viseur
  • Appuyez deux fois pour afficher le contenu de l'ensemble
  • Copiez le fichier .dSYM et le fichier .app dans un nouveau répertoire
  • cd dans un nouveau répertoire
  • Exécutez cette commande: atos -arch armv7 -o 'Vimeo.app' / 'Vimeo'
  • Le terminal entrera dans un mouvement interactif
  • Collez l'adresse mémoire et appuyez sur Entrée, elle affichera le nom de la méthode et le numéro de ligne
  • Sinon, entrez cette commande: atos -arch armv7 -o 'Vimeo.app' / 'Vimeo' Pour obtenir des informations pour une seule adresse
Alfie Hanssen
la source
4

La combinaison qui a fonctionné pour moi était:

  1. Copiez le fichier dSYM dans le répertoire où se trouvait le rapport de plantage
  2. Décompressez le fichier ipa contenant l'application ('décompressez MyApp.ipa')
  3. Copiez le fichier binaire de l'application de la charge utile éclatée résultante dans le même dossier que le rapport de plantage et le fichier de symboles (quelque chose comme "MyApp.app/MyApp")
  4. Importez ou re-symbolisez le rapport de plantage depuis l'organisateur de Xcode

En utilisant atos, je n'ai pas pu résoudre les informations de symbole correctes avec les adresses et les décalages qui figuraient dans le rapport de plantage. Quand j'ai fait cela, je vois quelque chose de plus significatif, et cela semble être une trace de pile légitime.

Sean Aitken
la source
3

J'ai dû faire beaucoup de piratage du script symbolicatecrash pour le faire fonctionner correctement.

Pour autant que je sache, symbolicatecrash nécessite actuellement que le .app soit dans le même répertoire que le .dsym. Il utilisera le .dsym pour localiser le .app, mais il n'utilisera pas le dsym pour trouver les symboles.

Vous devriez faire une copie de votre symbolicatecrash avant d'essayer ces correctifs qui le feront apparaître dans le dsym:

Autour de la ligne 212 dans la fonction getSymbolPathFor_dsymUuid

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

Autour de la ligne 265 dans la fonction matchesUUID

265             return 1;
JerryH
la source
1

C'est simple, après avoir beaucoup cherché, j'ai trouvé des étapes claires pour symboliser l'ensemble du fichier journal des plantages.

  • copiez les fichiers .app, crash_report et DSYM dans un dossier.
  • connecter l'appareil avec xcode
  • Ensuite, allez dans la fenêtre -> sélectionner les appareils -> afficher les journaux des appareils
  • Sélectionnez ensuite cet appareil, supprimez tous les journaux.
  • faites glisser et déposez votre crash sur la section du journal de l'appareil. il symbolisera automatiquement l'accident. faites un clic droit sur le rapport et exportez-le.

codage heureux,
Riyaz

Shaik Riyaz
la source
meilleurs ans courts et doux, suivez chaque étape écrite dans ce ans. developer.apple.com/library/content/technotes/tn2151/… suivez ce lien pour trouver la différence entre non symbolisé et entièrement symbolisé.
Ninad Kambli
1

Je préfère un script qui symbolisera tous mes journaux de plantage.

Conditions préalables

Créez un dossier et mettez-y 4 choses:

  1. symbolicatecrash script perl - il existe de nombreuses réponses SO qui indiquent son emplacement

  2. L'archive de la construction qui correspond aux plantages (de Xcode Organizer. Simple as Show in Finderand copy) [Je ne suis pas sûr que ce soit nécessaire]

  3. Tous les xccrashpointpackages - (depuis Xcode Organizer. Show in Finder, Vous pouvez copier tous les packages du répertoire ou le seul xccrashpoint que vous souhaitez symboliser)

  4. Ajoutez ce court script au répertoire:

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

Le scénario

Lorsque vous exécutez le script, vous obtiendrez 2 répertoires.

  1. allCrashes- tous les plantages de tous les xccrashpointseront là.

  2. symboledCrashes - les mêmes plantages mais maintenant avec tous les symboles.

  3. vous n'avez PAS besoin de nettoyer le répertoire des anciens plantages avant d'exécuter le script. il nettoiera automatiquement. bonne chance!

Yitzchak
la source
1

J'ai découvert que la plupart des alternatives proposées ne fonctionnaient pas dans le dernier XCode (testé avec Xcode 10). Par exemple, je n'ai pas eu de chance de glisser-déposer les journaux .crash dans Xcode -> Organizer -> Device logs -view.

Je recommande d'utiliser l'outil Symbolicator https://github.com/agentsim/Symbolicator

  • Git clone Symbolicator repository et compiler et exécuter avec Xcode
  • Copiez le fichier .crash (fichier ascii, avec trace de pile au début du fichier) et .xarchive de la version en panne dans le même dossier temporel
  • Faites glisser et déposez le fichier .crash sur l'icône Symbolicator dans le Dock
  • En 5-30 secondes, le fichier de crash symbolisé est produit dans le même dossier que .crash et .xarchive sont
Erkki Nokso-Koivisto
la source
0

Afin de symboliser les plantages, Spotlight doit pouvoir trouver le fichier .dSYM qui a été généré en même temps que le binaire que vous avez soumis à Apple. Puisqu'il contient les informations du symbole, vous n'aurez pas de chance s'il n'est pas disponible.

rpetrich
la source
Si vous lisez la question, j'ai déclaré que j'avais enregistré le fichier dSYM d'origine qui avait été généré en même temps que le binaire était soumis.
Jasarien
0

Je suis un peu grincheux sur le fait que rien ici ne semble "fonctionner", alors j'ai fait des recherches et le résultat est:

Configuration: backend QuincyKit qui reçoit les rapports. Aucune symbolisation établie car je ne pouvais même pas commencer à comprendre ce qu'ils suggéraient de faire pour que cela fonctionne.

La solution: téléchargez les rapports de plantage depuis le serveur en ligne. Ils s'appellent 'crash' et vont par défaut dans le dossier ~ / Downloads /. Dans cet esprit, ce script "fera la bonne chose" et les rapports de plantage iront dans Xcode (organiseur, journaux de périphérique) et la symbolisation sera effectuée.

Le scénario:

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

Les choses peuvent être automatisées à l'endroit où vous pouvez faire glisser et déposer dans Xcode Organizer en faisant deux choses si vous utilisez QuincyKit / PLCR.

Tout d'abord, vous devez éditer le script distant admin / actionapi.php ~ ligne 202. Il ne semble pas que l'horodatage soit correct, donc le fichier se retrouve avec le nom 'crash' que Xcode ne reconnaît pas (il veut quelque chose crash de points):

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

Deuxièmement, du côté iOS dans QuincyKit BWCrashReportTextFormatter.m ~ ligne 176, changez @"[TODO]"pour @"TODO"contourner les mauvais caractères.

Kalle
la source
0

atos est obsolète, donc si vous utilisez OSX 10.9 ou une version ultérieure, vous devrez peut-être exécuter

xcrun atos

Avertissement: / usr / bin / atos se déplace et sera supprimé d'une future version d'OS X. Il est désormais disponible dans les outils de développement Xcode pour être appelé via:xcrun atos


la source
Il semble qu'Apple permette au format DWARF de se métamorphoser avec chaque version des outils (c'est logique, en particulier avec l'avènement de Swift), ils le déplacent donc dans la distribution d'outils.
David Gish
0

J'aime utiliser Textwrangler pour identifier les erreurs dans un rejet binaire de téléchargement d'application d'origine. (Les données de plantage se trouvent dans votre compte itunesConnect.) En utilisant la méthode de Sachin ci-dessus, je copie le fichier original.crash dans TextWrangler, puis je copie le fichier symbolicatecrash que j'ai créé dans un autre fichier TextWrangler. La comparaison des deux fichiers met en évidence les différences. Le fichier symbolicatecrash aura des différences qui indiquent le fichier et le numéro de ligne des problèmes.

Homme de montagne
la source
-2

Nous utilisons Google Crashlytics pour superviser les journaux de plantage, le sentiment est très opportun et pratique à utiliser.

Liens vers le document: https://docs.fabric.io/apple/crashlytics/missing-dsyms.html#missing-dsymes

Tout sur Fabric dSYM manquant comprend un outil pour télécharger automatiquement le dSYM de votre projet. L'outil est exécuté via le script / run, qui est ajouté à votre phase d'exécution du script lors du processus d'intégration. Il peut toutefois y avoir certaines situations, lorsque les téléchargements dSYM échouent en raison de configurations de projet uniques ou si vous utilisez Bitcode dans votre application. Lorsqu'un téléchargement échoue, Crashlytics n'est pas en mesure de symboliser et d'afficher les plantages, et une alerte «Missing dSYM» apparaîtra sur votre tableau de bord Fabric.

Les dSYM manquants peuvent être téléchargés manuellement en suivant les étapes décrites ci-dessous.

Remarque: Comme alternative à l'outil de téléchargement automatisé dSYM, Fabric fournit un outil de ligne de commande (symboles de téléchargement)) qui peut être configuré manuellement pour s'exécuter dans le cadre du processus de génération de votre projet. Voir la section des symboles de téléchargement ci-dessous pour les instructions de configuration.

...

Tim
la source