ios probleme Symboles de l'application iPhone en cas de panne




probleme mise a jour application iphone (20)

Je cherche à symboliser les rapports d'erreur de mon application iPhone.

J'ai récupéré les rapports d'erreur d'iTunes Connect. J'ai l'application binaire 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 qui est 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 d'accident pour commencer, non symbolisé.

Est-ce que je fais quelque chose de mal?


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

Liens vers les documents: https://docs.fabric.io/apple/crashlytics/missing-dsyms.html#missing-dsyms

Tout à propos de Missing dSYMs Fabric inclut 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 Run Script Build Phase pendant le processus d'intégration. Cependant, il peut y avoir certaines situations où 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 ne peut pas symboliser et afficher des 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 automatique dSYM, Fabric fournit un outil de ligne de commande (symboles de téléchargement) qui peut être configuré manuellement pour être exécuté dans le cadre du processus de construction de votre projet. Voir la section des symboles de téléchargement ci-dessous pour les instructions de configuration.

...


Étapes à suivre pour analyser le rapport d'erreur d'apple:

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

  2. Ouvrez l'application de terminal et allez dans le dossier créé ci-dessus (en utilisant la commande cd )

  3. Exécutez atos -arch armv7 -o APPNAME.app/APPNAME MEMORY_LOCATION_OF_CRASH . L'emplacement de la mémoire devrait être celui où l'application s'est plantée selon le rapport.

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

Cela vous montrerait la ligne exacte, le nom de la méthode qui a abouti à un crash.

Ex: [classname functionName:]; -510 [classname functionName:]; -510

IPA symbolisant

si nous utilisons IPA pour symboliser - il suffit de renommer l'extension .ipa avec .zip, extrayez-le, nous pouvons obtenir un dossier de charge utile qui contient l'application. Dans ce cas, nous n'avons pas besoin de 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 de versions ont supprimé les symboles. Nous pouvons le modifier dans les paramètres de construction du projet "Strip Déboguer les symboles pendant la copie" sur NO.

Plus de détails voir cet post


La combinaison qui a fonctionné pour moi était:

  1. Copiez le fichier dSYM dans le répertoire où le rapport de panne a été
  2. Décompressez le fichier ipa contenant l'application ('unzip MyApp.ipa')
  3. Copiez le fichier binaire de l'application de la charge explosive résultante dans le même dossier que le rapport d'erreur et le fichier de symboles (quelque chose comme "MyApp.app/MyApp")
  4. Importer ou re-symboliser le rapport de plantage depuis l'organiseur de XCode

En utilisant atos, je n'ai pas été capable de résoudre les informations de symboles correctes avec les adresses et les décalages qui se trouvaient dans le rapport d'accident. Quand je l'ai fait, je vois quelque chose de plus significatif, et il semble être une trace de pile légitime.


Dans mon cas, je faisais glisser des rapports d'erreur directement depuis Mail vers l'organisateur. Pour une raison quelconque, cela a empêché les rapports d'accident de devenir symboliques (j'aimerais savoir pourquoi).

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

Cas très particulier, je sais. Mais je pensais partager juste au cas où.


Je mets également dsym, bundle d'application, et le journal de panne ensemble dans le même répertoire avant d'exécuter le crash de symbolicate

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 ajoutés ici peuvent vous aider.

Vous pouvez vérifier que Spotlight "voit" vos fichiers dysm en lançant la commande:

mdfind 'com_apple_xcode_dsym_uuids = *'

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

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

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


Après avoir lu toutes ces réponses ici pour symboliser un crash log (et finalement réussir), je pense qu'il manque quelques points 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'emboîter lorsqu'ils symbolisent un journal de plantage:

  1. Le fichier journal de plantage lui-même (par exemple, example.crash ), exporté depuis l'organiseur de XCode ou reçu depuis iTunes Connect.
  2. Le package .app ( example.app ) qui contient lui-même le binaire de l'application appartenant au journal de plantage. Si vous avez un paquet .ipa (ie example.ipa ) alors vous pouvez extraire le paquet .app en décompressant le paquet .ipa (ie unzip example.ipa ). Ensuite, le package .app réside dans le dossier Payload/ extrait.
  3. Le paquet .dSYM contenant les symboles de débogage (exemple: example.app.dSYM )

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

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

...
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 aa5e633efda8346cab92b01320043dc3 appartient à une image binaire de l'application nommée example.app/example avec UUID aa5e633efda8346cab92b01320043dc3 .

Vous pouvez vérifier l'UUID du paquet 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 également appartiennent à 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 éléments s'emboîtent et vous devriez pouvoir symboliser votre pile de pile.

Passant au script symbolicatecrash :

Dans Xcode 8.3, vous devriez pouvoir appeler le script via

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

Si ce n'est pas le cas, vous pouvez lancer une find . -name symbolicatecrash 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 de 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 paquets dSYM indexés et la seconde vous donne les paquets .dSYM avec un UUID spécifique. Si Spotlight ne trouve pas votre paquet .dSYM alors symbolicatecrash ne le fera pas non plus. Si vous faites tout cela, par exemple dans un sous-dossier de votre projecteur ~/Desktop devrait être capable de tout trouver.

Si symbolicatecrash trouve votre paquet .dSYM , 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 paquet .app 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 symbolicatecrash trouve votre paquet .app , 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 par symbolicatecrash il devrait imprimer la version symbolisée de votre journal de plantage.

Sinon, vous pouvez transmettre vos fichiers dSYM et .app directement.

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 symbolique sera sortie vers le terminal et non symbolicate.log .


Étapes pour symboliser un rapport d'erreur automatiquement en utilisant XCode:

MISE À JOUR POUR XCODE 9

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

  2. Choisissez "Appareils" dans le menu "Fenêtre"

  3. Cliquez sur votre appareil sur la gauche et afficher les journaux de périphériques sur la droite

  4. Attendez. Cela peut prendre une minute pour apparaître. Peut Command-A être que faire Command-A puis Delete va accélérer cela.

  5. Étape critique non documentée: renommez le rapport d'erreur que vous avez reçu de iTunesConnect de l'extension .txt extension .crash

  6. Faites glisser le rapport d'accident dans cette zone sur la gauche

Ensuite, Xcode symbolisera le rapport d'erreur et affichera les résultats.

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


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

Conditions préalables

Créer un dossier et y mettre 4 choses:

  1. symbolicatecrash Perl Script - il y a beaucoup de réponses SO qui indique son emplacement

  2. Les archives de la construction qui correspondent aux plantages (de Xcode Organizer, simple comme Show in Finder et copier) [Je ne suis pas sûr que ce soit nécessaire]

  3. Tous les paquets xccrashpoint - (à partir de Xcode Organizer. Show in Finder , vous pouvez copier tous les paquets dans le répertoire, ou le seul xccrashpoint que vous aimeriez 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 script

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

  1. allCrashes - tous les plantages de tous les xccrashpoint seront là.

  2. symboledCrashes - les mêmes accidents 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 va nettoyer automatiquement. bonne chance!


Dans XCode 4.2.1, ouvrez Organizer, puis allez dans Library / Device Logs et faites glisser votre fichier .crash dans la liste des journaux de plantage. Il sera symbolisé pour vous après quelques secondes. Notez que vous devez utiliser la même instance de XCode que la version d'origine a été archivée (c'est-à-dire que l'archive de votre version doit exister dans Organizer).


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

Configurer: back-end QuincyKit qui reçoit les rapports. Aucune symbolisation mise en place que je ne pouvais même pas commencer à comprendre ce qu'ils suggéraient que je fais pour le faire fonctionner.

La solution: téléchargez les rapports d'erreur du serveur en ligne. Ils s'appellent 'crash' et par défaut vont dans le dossier ~ / Downloads /. Dans cet esprit, ce script «fera le bon choix» et les rapports d'erreur iront dans Xcode (organisateur, journaux de l'appareil) et la symbolisation sera faite.

Le 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"

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 semble que l'horodatage ne soit pas correct, donc le fichier se termine par le nom 'crash' que Xcode ne reconnaît pas (il veut quelque chose point d'accident):

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

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


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

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

Vous devriez faire une copie de votre symbolicatecrash avant d'essayer ces patchs 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;

atos est obsolète, donc si vous utilisez OSX 10.9 ou plus tard, vous devrez peut-être courir

xcrun atos

Attention: / usr / bin / atos est en cours de suppression et sera supprimé d'une future version d'OS X. Il est maintenant disponible dans les outils de développement Xcode à xcrun atos via: xcrun atos


En utilisant XCode 4, la tâche est encore plus simple:

  • ouvrir Organizer,
  • cliquez sur la bibliothèque | Device Log 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 construction en utilisant XCode -> Product -> Archive first


L'organisateur magique de XCode n'est pas magique pour symboliser mon application. Je n'ai reçu aucun symbole pour les rapports d'accident que j'ai reçus d'Apple suite à une demande d'inscription ratée.

J'ai essayé d'utiliser la ligne de commande, en plaçant le rapport d'erreur 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 de la fondation, mais c'était mieux que le vidage de nombre que l'organisateur me donnait et était suffisant pour que je trouve et répare le crash de mon application. Si quelqu'un sait comment étendre cela pour obtenir des symboles de la Fondation, ce serait apprécié.


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 de mémoire mais pas d'autres, je ne sais pas pourquoi ...

  • Créer un nouveau répertoire sur le bureau ou ailleurs
  • Trouver l'archive en question dans l'organiseur Xcode
  • Appuyez deux fois pour révéler dans le Finder
  • Appuyez deux fois pour afficher le contenu du bundle
  • Copiez le fichier .dSYM et le fichier .app dans le nouveau répertoire
  • cd dans un nouveau dir
  • Exécutez cette commande: atos -arch armv7 -o 'Vimeo.app' / 'Vimeo'
  • Terminal entrera dans un mouvement interactif
  • Coller dans l'adresse de la mémoire et appuyez sur Entrée, il sortira le nom de la méthode et le numéro de ligne
  • Vous pouvez également entrer cette commande: atos -arch armv7 -o 'Vimeo.app' / 'Vimeo' Pour obtenir des informations pour une seule adresse

J'aime utiliser Textwrangler pour identifier les erreurs dans un rejet binaire de téléchargement d'application originale. (Les données de l'accident seront trouvées dans votre compte itunesConnect.) En utilisant la méthode de Sachin ci-dessus, je copie l'original.crash à TextWrangler, puis copiez 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.


Voici un autre problème que j'ai avec symbolicatecrash - il ne fonctionnera pas avec les applications qui ont des espaces dans leur bundle (ie 'Test App.app'). Note Je ne pense pas que vous puissiez avoir des espaces dans leur nom lors de la soumission, donc vous devriez les enlever de toute façon, mais si vous avez déjà des plantages qui ont besoin d'être analysés, corrigez symbolicatecrash (4.3 GM) comme 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\"";

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

  • copier les fichiers .app, crash_report et DSYM dans un dossier.
  • connectez l'appareil avec xcode
  • Ensuite, allez dans la fenêtre -> sélectionnez les périphériques -> afficher les journaux de l'appareil
  • Sélectionnez ensuite cet appareil, supprimez tous les journaux.
  • glisser et déposer votre accident sur la section du journal de l'appareil. cela symbolisera automatiquement le crash. faites un clic droit sur le rapport et exportez-le.

codage heureux,
Riyaz


Pour symboliser les plantages, Spotlight doit être capable de trouver le fichier .dSYM qui a été généré en même temps que le binaire que vous avez envoyé à Apple. Comme il contient les informations sur les symboles, vous n'aurez pas de chance s'il n'est pas disponible.


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

1- Premièrement, allez sur itunesconnect et téléchargez vos journaux de plantage. NOTE: 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 de plantage à Apple, auquel cas vous ne pouvez pas faire grand-chose à ce stade.

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