Analyse CrashReport pour debuggage
LeChatNoir
Membre, Modérateur
Salut,
Sur la dernière version de ClimbingAway, qui a subit un gros gros remaniement de code, j'ai pas mal de crashs.
Sur Flurry, J'ai les 3 crashs les plus fréquents à dispo et je peux dl les fichiers crashreports.
Mais en fait, j'avoue que je suis noob là dessus. Comment faire pour les exploiter.
Comment savoir quelles valeurs étaient utilisées lors du crash.
Car J'ai un double pb : il faudrait que je sache où se produit le crash dans le code, ça c'est la base. Et ensuite, il faudrait que je sache dans quel contexte ça se produit car avec 5400 sites de grimpe, je soupçonne que c'est le jeu de données qui pose pb parfois.
Des pistes pour me lancer sur la traque infernale ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Hello,
Voici un lien :
https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/AnalyzingCrashReports/AnalyzingCrashReports.html
ah ouais. Ca a l'air puissant ! Décidément, XCode évolue plus vite que moi !
Merci !
Par contre dans un CrashReport, tu n'as pas directement accès aux paramètres qui ont été utilisés lors dudit crash. Tu peux savoir quelle méthode a été appelée, mais pas avec quels paramètres, ce n'est pas remonté dans le rapport de crash.
Le mieux si tu veux + de contexte est d'utiliser des outils de logging pour cela. Par exemple avec Crashlytics, il y a une méthode de log dédiée qui permet d'associer des logs à un CrashReport. Bon, je l'ai jamais trop testée en pratique donc je ne connais pas le détail, mais de ce que j'ai compris du fonctionnement, c'est que tu appelles CLLog(...), ça mémorise le message de log que tu lui passes, et si jamais l'appli crash, ça va t'associer ces messages de log au CrashReports dans l'interface de Crashlytics pour que tu aies un peu + de contexte.
Je ne sais pas si Flurry propose le même genre d'outil / de possibilité, mais ça vaut le coup de regarder. Si c'est le cas, ça veut quand même dire qu'il faudra que tu refasse une version où tu mets des logs un peu partout où ça te semble utile pour avoir ces informations, et attendre que ça recrash, vu que tu n'avais pas mis ces logs initialement, c'est un peu dommage, mais bon.
Après, peut-être que juste la callstack (liste des méthodes appelées) te suffit déjà pour mieux identifier où ça a planté déjà , c'est de toute façon une première étape qui te permettra de mieux cibler où est le problème (d'où l'intérêt de plutôt bien découper ton code en terme d'architecture et de préférer plein de petites méthodes plutôt qu'une grosse méthode, comme ça si tu sais dans quelle méthode ça a crashé, si le code de cette méthode est assez court c'est facile à isoler).
Ok, je vais me pencher sur tout ça et je vous tient au jus si j'en dire des leçons intéressantes.
++ et merci
Normalement Xcode fait cela tout seul : quand tu génères une "Archive" (Product -> Archive) dans le but de la soumettre ensuite sur l'AppStore via Xcode, en fait cette "Archive" est juste un petit bundle contenant à la fois le .ipa et le .dSYM, ce qui permet de garder tout ça de côté. Et quand tu soumets à Apple je me demande si ça n'envoie pas aussi le dSYM (pour qu'ils soient capables de le symboliser sur leurs serveurs pour quand tu consultes les CrashLogs depuis iTunes Connect, ça me semblerait la seule façon qu'ils puissent le faire).
Mais du coup si tu supprimes dans Xcode l'Archive qui t'a servi à soumettre ton app sur l'AppStore, tu supprimes par la même occasion le dSYM, et du coup tu ne pourras plus symboliser les crashlogs que tes utilisateurs ou Flurry t'enverront pour les transformer en trucs lisibles. Donc c'est quand même une bonne idée de garder les Archives des applications soumises sur le store pour pouvoir débuguer les CrashLogs quand tu en reçois
Ca tombe bien, je les garde