L'organisateur de Xcode 5 avait une vue qui listerait tous les journaux de crash. et nous pourrions faire glisser déposer les journaux de crash ici. Mais depuis Xcode 6, je sais qu’ils ont sorti leurs appareils de l’organisation et ont une nouvelle fenêtre pour les mêmes. Mais je ne trouve pas d’endroit où j’affiche les journaux de collisions que j’ai glissés dans Xcode 5 après avoir passé à Xcode 6. Quelqu'un connaît la réponse?
Ok je me suis rendu compte que vous pouvez faire ceci:
Xcode > Window > Devices
, sélectionnez un iPhone/iPad/etc connecté en haut à gauche.Vous avez probablement beaucoup de journaux là-bas, et pour faciliter la recherche de votre journal importé plus tard, vous pouvez simplement supprimer tous les journaux à ce stade ... à moins qu'ils ne signifient de l'argent. Ou à moins que vous ne connaissiez le moment exact où le crash s'est produit - il devrait quand même être écrit dans le fichier ... Je suis paresseux, je supprime donc tous les anciens journaux (cela a pris un peu de temps).
Écrire cette réponse autant pour la communauté que pour moi-même.
S'il existe des problèmes symbolisant un rapport d'incident, vous pouvez les résoudre comme suit:
Créez un dossier séparé, copiez Foo.app
et Foo.app.dSYM
à partir du .xcarchive
correspondant dans le dossier. Copiez également le rapport .crash
dans le dossier.
Ouvrez le rapport d'incident dans TextEdit ou ailleurs, accédez à la section Binary Images:
et copiez la première adresse à cet endroit (par exemple 0xd7000
).
cd
dans le dossier. Maintenant, vous pouvez exécuter la commande suivante:
xcrun atos -o Foo.app/Foo -Arch arm64 -l 0xd7000 0x0033f9bb
Cela symbolisera le symbole à l'adresse 0x0033f9bb
. Assurez-vous de choisir la valeur correcte pour l'option -Arch
(vous pouvez l'obtenir à partir de la première ligne de la section Binary Images:
ou à partir de Hardware Model:
dans le rapport de blocage et de l'application. arcades soutenues).
Vous pouvez également copier les adresses nécessaires (par exemple, une pile d'appels de fils) du rapport d'incident directement dans un fichier texte (dans TextEdit, maintenez Option et sélectionnez le bloc de texte nécessaire, ou copiez et coupez), pour obtenir un résultat semblable à celui-ci:
0x000f12fb
0x002726b7
0x0026d415
0x001f933b
0x001f86d3
Vous pouvez maintenant enregistrer cela dans un fichier texte, par exemple. addr.txt
et exécutez la commande suivante:
xcrun atos -o Foo.app/Foo -Arch arm64 -l 0xd7000 -f addr.txt
Cela donnera une symbolique de Nice pour toutes les adresses à la fois.
P.S.
Avant de faire ce qui précède, il est utile de vérifier que tout est configuré correctement (car atos
signalera quelque chose avec plaisir pour l’ensemble des adresses fournies).
Pour effectuer la vérification, ouvrez le rapport d'incident et accédez à la fin de la pile d'appels pour Thread 0
. La première ligne à partir de la fin répertorie votre application (généralement la deuxième), par exemple:
34 Foo 0x0033f9bb 0xd7000 + 2525627
devrait être l'appel main()
. La symbolique de l'adresse (0x0033f9bb
dans ce cas) comme indiqué ci-dessus devrait confirmer qu'il s'agit bien de main()
et non d'une méthode ou fonction aléatoire.
Si l'adresse n'est pas celle de main()
, vérifiez votre adresse de chargement (option -l
) et Arch (option -Arch
).
P.P.S.
Si ce qui précède ne fonctionne pas car bitcode, téléchargez le dSYM correspondant à votre version à partir d’iTunes Connect, extrayez le fichier binaire exécutable du dSYM (Finder> Afficher le contenu du package), copiez-le dans le répertoire et utilisez-le (c.-à-d. Foo
) comme argument de atos
au lieu du Foo.app/Foo
.
Vous pouvez aussi vous référer à celui-ci, j’ai écrit la procédure étape par étape de Réécriture manuelle d’une nouvelle collision .
ÉTAPE 1
Déplacez tous les fichiers ci-dessus (MyApp.app, MyApp-dSYM.dSYM et MyApp-Crash-log.crash) dans un dossier avec un nom pratique partout où vous pouvez utiliser Terminal facilement.
Pour moi, Desktop est l’endroit le plus facilement accessible;) Ainsi, j’ai déplacé ces trois fichiers dans un dossier MyApp at Desktop.
ÉTAPE 2
C’est maintenant au tour du Finder, de choisir le chemin qui convient pour votre version de XCODE.
Utilisez cette commande pour trouver le fichier de script symbolicatecrash
,find /Applications/Xcode.app -name symbolicatecrash
Xcode 8, Xcode 9 /Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash
Xcode 7.3 /Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash
XCode 7 /Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash
Xcode 6 /Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources
Diminuez ensuite Xcode 6 Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources
Ou Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources
ÉTAPE 3
Ajoutez le répertoire du fichier de script symbolicatecrash trouvé à la variable $PATH
, comme ceci: Sudo vim /etc/paths.d/Xcode-symbolicatecrash
, collez le répertoire du fichier de script et enregistrez-le. Lorsque vous ouvrez un nouveau terminal, vous pouvez appeler symbolicatecrash
dans n’importe quel dossier en tant que commandes situées dans /usr/bin
.
Ou
Copiez le fichier symbolicatecrash à partir de cet emplacement et collez-le dans le bureau/MonApp (Attendez… Ne me suivez pas aveuglément, je colle le fichier sybolicatecrash dans le dossier MyApp, celui que vous avez créé à l'étape 1 à votre emplacement favori et contenant trois fichiers. )
ÉTAPE 4
Ouvrez le terminal et le CD dans le dossier MyApp.
cd Desktop/MyApp — Press Enter
export DEVELOPER_DIR=$(xcode-select --print-path)
- Appuyez sur Entrée
./symbolicatecrash -v MyApp-Crash-log.crash MyApp.dSYM
- Appuyez sur Entrée
C'est ça !! Des journaux symboliques sont sur votre terminal… maintenant, qu'attendez-vous? Maintenant, trouvez simplement l'erreur et résolvez-la;)
Bonne codage !!!
Il existe un moyen plus simple d’utiliser Xcode (sans utiliser d’outils de ligne de commande et sans rechercher les adresses une à une).
Prenez n'importe quel fichier .xcarchive. Si vous en avez un d'avant, vous pouvez l'utiliser. Si vous n'en avez pas, créez-en un en exécutant Product> Archive from Xcode.
Cliquez avec le bouton droit sur le fichier .xcarchive et sélectionnez "Afficher le contenu du paquet".
Copiez le fichier dsym (de la version de l'application qui est tombée en panne) dans le dossier dSYMs.
Copiez le fichier .app (de la version de l'application qui s'est écrasée) dans le dossier Produits> Applications.
Editez Info.plist et éditez CFBundleShortVersionString et CFBundleVersion dans le dictionnaire ApplicationProperties. Cela vous aidera à identifier les archives plus tard
Double-cliquez sur .xcarchive pour l'importer dans Xcode. Il devrait ouvrir l'organisateur.
Revenir au journal des incidents (dans la fenêtre Périphériques de Xcode)
Faites glisser votre fichier .crash ici (s'il n'est pas déjà présent)
L'ensemble du journal des incidents doit maintenant être symbolisé. Sinon, cliquez avec le bouton droit de la souris et sélectionnez 'Re-symbolicate crash log'
Pour moi, le fichier .crash était suffisant. Sans fichier .dSYM et fichier .app.
J'ai couru ces deux commandes sur le mac où je construis l'archive et cela a fonctionné:
export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer"
/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash /yourPath/crash1.crash > /yourPath/crash1_symbolicated.crash
Suivez ces étapes dans Xcode 10 pour symboliser un journal des incidents à partir d'une application construite sur le même ordinateur:
Si vous avez le fichier .dSYM et le fichier .crash dans le même sous-dossier, procédez comme suit:
$ atos -Arch arm64 -o TheElements.app.dSYM/Contents/Resources/DWARF/TheElements -l 0x1000e4000 0x00000001000effdc -[AtomicElementViewController myTransitionDidStop:finished:context:]
Source faisant autorité: https://developer.Apple.com/library/content/technotes/tn2151/_index.html#//Apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATE_WITH_ATOS
Assurez-vous que le nom de votre application Xcode ne contient aucun espace. C'est la raison pour laquelle cela n'a pas fonctionné pour moi. Donc, /Applications/Xcode.app
fonctionne, alors que /Applications/Xcode 6.1.1.app
ne fonctionne pas.
De la documentation d'Apple:
Symboles des rapports d'incident avec Xcode Xcode tentera automatiquement de symboliser tous les rapports d'incident qu'il rencontre. Tout ce que vous devez faire pour la symbolique est d’ajouter le rapport de plantage à l’organisateur Xcode.
Xcode symbolise automatiquement le rapport d'incident et affiche les résultats. Pour symboliser un rapport d'incident, Xcode doit pouvoir localiser les éléments suivants:
L'application binaire et le fichier dSYM de l'application en panne.
Fichiers binaires et fichiers dSYM de tous les cadres personnalisés auxquels l'application est liée. Pour les frameworks construits à partir des sources avec l'application, leurs fichiers dSYM sont copiés dans l'archive à côté du fichier dSYM de l'application. Pour les frameworks construits par un tiers, vous devrez demander à l'auteur le fichier dSYM.
Symboles pour le système d'exploitation sur lequel cette application était en cours d'exécution lorsqu'elle s'est effondrée. Ces symboles contiennent des informations de débogage pour les infrastructures incluses dans une version de système d'exploitation spécifique (par exemple, iOS 9.3.3). Les symboles de système d'exploitation sont spécifiques à l'architecture: une version d'iOS pour les périphériques 64 bits n'inclut pas de symboles armv7. Xcode copiera automatiquement les symboles du système d'exploitation de chaque appareil connecté à votre Mac.
Si l'un d'entre eux manque, Xcode risque de ne pas pouvoir symboliser le rapport d'incident ou de ne symboliser que partiellement le rapport d'incident.
Le processus le plus simple pour symboliser les journaux d'incidents:
Attendez 5 secondes. Coup! les appels d'application en trace de pile seront symbolisés! Vous pouvez toujours voir beaucoup de symboles cependant! ce sont des appels internes à la bibliothèque et au framework.
C'est le plus facile, essayé et testé!