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?
ios
crash-reports
symbolicate
Jasarien
la source
la source
symbolicatecrash
commande, comment l'utiliser et comment trouver le fichier dSYM nécessaire pour effectuer la symbolisation.Réponses:
Étapes pour analyser le rapport de plantage d'Apple:
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 .
Ouvrez l'application terminal et accédez au dossier créé ci-dessus (à l'aide de la
cd
commande)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
la source
atos -o myApp.app/Contents/MacOS/myApp 0x0000000100001f2c
et vous obtenez-[HUDWindow sizedHUDBackground] (in myApp) + 1197
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:
example.crash
), soit exporté de l'organisateur de XCode, soit reçu d'iTunes Connect..app
package (c'est-à-direexample.app
) qui contient lui-même le binaire d'application appartenant au journal des plantages. Si vous avez un.ipa
package (ieexample.ipa
), vous pouvez extraire le.app
package en décompressant le.ipa
package (ieunzip example.ipa
). Ensuite, le.app
paquet réside dans le fichier extraitPayload/
dossier ..dSYM
paquet contenant les symboles de débogage (ieexample.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:
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:
Ensuite, vous devriez vérifier si les symboles de débogage que vous avez appartiennent également à ce binaire:
Dans cet exemple, tous les actifs s'assemblent et vous devriez pouvoir symboliser votre stacktrace.
Procéder au
symbolicatecrash
script:Dans Xcode 8.3, vous devriez pouvoir invoquer le script via
S'il n'est pas là, vous pouvez exécuter un
find . -name symbolicatecrash
dans 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:resp.
La première invocation Spotlight vous donne tous les packages dSYM indexés et la seconde vous donne les
.dSYM
packages avec un UUID spécifique. Si Spotlight ne trouve pas votre.dSYM
colis, ilsymbolicatecrash
ne 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
symbolicatecrash
trouve votre.dSYM
colis, il devrait y avoir une ligne comme celle-ci danssymbolicate.log
:Pour trouver votre
.app
package, une recherche Spotlight comme celle-ci est invoquée parsymbolicatecrash
:Si
symbolicatecrash
trouve votre.app
paquet, il devrait y avoir l'extrait suivant danssymbolicate.log
:Si toutes ces ressources sont trouvées,
symbolicatecrash
il devrait imprimer la version symbolisée de votre journal des plantages.Sinon, vous pouvez directement transmettre vos fichiers dSYM et .app.
Remarque: La trace symbolisée sera sortie vers le terminal, non
symbolicate.log
.la source
No crash report version in testlog.crash at /usr/bin/symbolicatecrash line 921.
DEVELOPER_DIR
variable 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<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)
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)
la source
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
cd / Users / mac38 / Desktop / CrashReport et appuyez sur le bouton Entrée
export DEVELOPER_DIR = "/ Applications / Xcode.app / Contents / Developer" et appuyez sur Entrée
la source
Unknown option: A
pour symbolicatecrash, mais le processus a quand même fonctionnéÉtapes pour symboliser automatiquement un rapport d'erreur à l'aide de XCode:
MIS À JOUR POUR XCODE 9
Connectez n'importe quel appareil iOS à votre Mac (oui physique, oui je sais que c'est stupide)
Choisissez "Appareils" dans le menu "Fenêtre"
Cliquez sur votre appareil à gauche et VOIR LES JOURNAUX DES APPAREILS à droite
Attendre. Cela peut prendre une minute pour apparaître. Peut-être que faire
Command-A
alorsDelete
accélérera cela.Étape critique non documentée: renomme le rapport accident que vous avez obtenu de iTunesConnect d'
.txt
extension à.crash
extensionFaites glisser le rapport de crash dans cette zone à gauche
Et puis Xcode symbolisera le rapport de plantage et affichera les résultats.
Source: https://developer.apple.com/library/ios/technotes/tn2151/_index.html
la source
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:
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é.
Dans Terminal, cd dans le xcarchive par exemple
MyCoolApp 10-27-11 1.30 PM.xcarchive
Entrez les informations suivantes
atos -arch armv7 -o 'MyCoolApp.app'/'MyCoolApp'
(n'oubliez pas les guillemets simples)Je n'inclus pas mon symbole dans cet appel. Ce que vous obtenez est un curseur de bloc sur une ligne vide.
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)
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!
la source
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:
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:
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
la source
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.
la source
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.
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.
la source
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 ).
la source
Avec Xcode 4, la tâche est encore plus simple:
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.
la source
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:
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é.
la source
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ù.
la source
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:
la source
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 ...
la source
La combinaison qui a fonctionné pour moi était:
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.
la source
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
Autour de la ligne 265 dans la fonction matchesUUID
la source
C'est simple, après avoir beaucoup cherché, j'ai trouvé des étapes claires pour symboliser l'ensemble du fichier journal des plantages.
codage heureux,
Riyaz
la source
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:
symbolicatecrash
script perl - il existe de nombreuses réponses SO qui indiquent son emplacementL'archive de la construction qui correspond aux plantages (de Xcode Organizer. Simple as
Show in Finder
and copy) [Je ne suis pas sûr que ce soit nécessaire]Tous les
xccrashpoint
packages - (depuis Xcode Organizer.Show in Finder
, Vous pouvez copier tous les packages du répertoire ou le seul xccrashpoint que vous souhaitez symboliser)Ajoutez ce court script au répertoire:
Le scénario
Lorsque vous exécutez le script, vous obtiendrez 2 répertoires.
allCrashes
- tous les plantages de tous lesxccrashpoint
seront là.symboledCrashes
- les mêmes plantages mais maintenant avec tous les symboles.vous n'avez PAS besoin de nettoyer le répertoire des anciens plantages avant d'exécuter le script. il nettoiera automatiquement. bonne chance!
la source
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
la source
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.
la source
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:
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):
Deuxièmement, du côté iOS dans QuincyKit BWCrashReportTextFormatter.m ~ ligne 176, changez
@"[TODO]"
pour@"TODO"
contourner les mauvais caractères.la source
atos est obsolète, donc si vous utilisez OSX 10.9 ou une version ultérieure, vous devrez peut-être exécuter
xcrun atos
la source
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.
la source
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.
...
la source