Crash logs générés par iPhone Simulator?

96

Y a-t-il des journaux de crash générés par iPhone Simulator?

le simulateur plante beaucoup mais ne laisse aucune trace dans la console ... le journal des plantages sera utile.

iphone ios-simulator crash-reports

— Raptor
source

2

Je ne comprends pas très bien pourquoi vous avez besoin des journaux des pannes. Lorsque l'application se bloque dans le simulateur mais avant d'arrêter le débogage, à l'invite gdb, tapez "bt" pour "backtrace" - vous obtiendrez exactement ce qui apparaîtrait dans le journal des plantages. (je ne savais pas qu'il y avait une question de nécromancie ici, a raté l'année post)

— Matthew Frederick

3

Si le crash ne s'est produit que lorsque vous n'étiez pas attaché par le débogueur, vous auriez besoin des journaux.

— Ian1971

vous avez raison. cela a du sens!

— Raptor

Vous pouvez également voir le journal de débogage (y compris la sortie des commandes lldb) dans le "Navigateur de rapports" dans Xcode (cmd-8). Ceci est également utile pour voir la sortie de débogage des exécutions précédentes. Si le débogueur n'était pas attaché, cela ne fonctionnera évidemment pas.

— Sebastien Martin

2

Le journal de débogage n'est pas le même que le journal de panne, bien que les deux journaux soient utiles pour déboguer le problème.

— Raptor

157

La console affichera la NSLog()sortie d'une application exécutée dans le simulateur. Les journaux de plantage sont enregistrés dans un fichier.

J'en ai trouvé dans mon répertoire personnel sous

~/Library/Logs/DiagnosticReports/

Ils ont une extension de fichier de .crash

Quelque chose que je n'ai pas encore compris, c'est comment les faire générer même si le débogueur saisit le EXC_BAD_ACCESSsignal.

Mettre à jour

Actuellement, (OSX 10.11.6), le .crash se connecte ~/Library/Logs/DiagnosticReports, c'est quand l'émulateur lui-même se bloque . Les journaux pour une application en panne (mais le périphérique émulateur fonctionne toujours correctement), sont dans:

~ / Bibliothèque / Logs / CoreSimulator

Par crash, il y a un sous-dossier avec un identifiant unique. Trier par date, de sorte que votre récent crash soit le premier sous-dossier. À l'intérieur de cela, commencez par regarder stderr.loget system.log.

Aussi directement sous CoreSimulator, voir CoreSimulator.loget Simulator.log.

— ohhorob
source

Une idée de la raison pour laquelle ces journaux sont écrits dans un fichier au lieu de s'afficher dans la console? Merci pour l'info, btw.

— aqua

11

Aucun de mes rapports de plantage dans le simulateur iPhone ou iPad n'apparaît sous ce répertoire, peut-être que cette réponse doit être mise à jour?

— Justin

3

Il faut peut-être une mise à jour, mais un vote défavorable n'est pas une façon très polie de l'encourager.

— ohhorob

2

J'ai trouvé le rapport de plantage dans le répertoire mentionné, mais il n'y avait qu'un seul rapport et ce n'était pas le plus récent (c'est-à-dire que j'ai continué à essayer quelques choses dans l'application et il a continué à planter). Les plantages étaient tous les mêmes, donc ce n'était pas un problème, mais je me demande si c'est généralement le cas?

— Samik R

10

Justin et Ohhorob ont tous deux raison. Vous devez lancer l'application sur le simulateur SANS Xcode et reproduire le crash pour voir les logs~/Library/Logs/DiagnosticReports/

— Dave Chambers

20

Je suis presque sûr que vous pouvez le voir dans l'application Console OS X située dans Utilitaires. Si je me trompe, assurez-vous de voter pour moi afin que je supprime ceci.

METTRE À JOUR:

Plus précisément (à partir d'OSX 10.11.6),

Lorsqu'une application plante sur l'émulateur, un sous-dossier (avec un identifiant unique) est ajouté à:

~ / Bibliothèque / Logs / CoreSimulator

À l'intérieur de cela, commencez par examiner stderr.loget system.log.

Lorsque l'émulateur lui-même plante, un sous-dossier est ajouté à:

~ / Bibliothèque / Journaux / Rapports de diagnostic

Ne confondez pas ce chemin avec

/ Bibliothèque / Journaux

(manquant ~au début), qui a différents rapports sur votre mac.

— bpapa
source

Oui. Plus d'informations ici developer.apple.com/iphone/library/documentation/Xcode/…

— Brandon Bodnar

semble que cela ne s'applique qu'aux appareils iPhone, au lieu du simulateur. Corrigez-moi si je me trompe.

— Raptor

7

La console peut être ouverte à partir du simulateur en appuyant sur Cmd- / ou en utilisant l'option de menu Déboguer / Ouvrir le journal système ...

— lambmj

5

Voici quelque chose qui a fonctionné pour moi dans un cas particulier ... Mon application plantait avec SIGKILL à la fin. Je verrais l'exception dans main.m pendant quelques secondes, puis l'application finirait de se terminer - donc, aucune chance d'obtenir la trace arrière.

J'ai fait beaucoup de recherches sur «où le simulateur stocke ses journaux de crash» et je n'ai jamais réussi à trouver une réponse. Cependant, l'astuce suivante m'a été très utile et j'ai pu récupérer le journal des accidents à la volée:

Fondamentalement, ouvrez /Applications/Utilities/CrashReporterPrefs.app et modifiez le paramètre sur «Developer». Cela entraînera CrashReporter à afficher une fenêtre contextuelle avec le journal des plantages après le crash de votre application.

J'ai trouvé ceci dans la section «Affichage de la console du simulateur iOS et des journaux de panne» de ce document d'Apple: http://developer.apple.com/library/ios/#documentation/Xcode/Conceptual/ios_development_workflow/125-Using_iOS_Simulator/ios_simulator_application. html

— dana_a
source

À propos, le problème initial avec SIGKILL que je recherchais s'est avéré être un non-problème: stackoverflow.com/questions/7901262/…

— dana_a

Je dois souligner qu'il n'y avait pas d'application CrashReporterPrefs dans Application / Utilities, mais je l'ai recherchée et j'ai pu trouver l'application ailleurs.

— Justin

@Justin où l'avez-vous trouvé?

— Ohad Schneider

1

Notez que l'outil mentionné ci-dessus est téléchargeable à partir de Xcode dans un ensemble appelé "Outils supplémentaires pour Xcode" developer.apple.com/download/more/…

— markshiz

1

C'est beaucoup plus fiable. En seulement quelques étapes, j'ai pu trouver le numéro de ligne source et le nom de la méthode:

cd dans le répertoire contenant les fichiers .app et .dSYM
exécutez /Developer/Platforms/iPhoneOS.platform/Developer/usr/libexec/gdb/gdb-arm-apple-darwin MyApp.app/MyApp
activer print asm-demangle
activer le nom de fichier de symbole d'impression
p / a 0 × 00015c64 -> adresse obtenue en ouvrant le journal des plantages dans l'application «Console» ou en double-cliquant simplement sur le fichier .crash.

— Point gamma
source

3

Je ne comprends pas très bien pourquoi vous avez besoin des journaux des pannes. Lorsque l'application se bloque dans le simulateur mais avant d'arrêter le débogage, à l'invite gdb, tapez "bt" pour "backtrace" - vous obtiendrez exactement ce qui apparaîtrait dans le journal des plantages.

— Matthew Frederick

Cette méthode fonctionne très bien pour les journaux des pannes des téléphones clients.

— Gamma-Point du

1

Les journaux de crashs apparaîtront sous ~ / Library / Logs / CrashReporter.

Si le programme du simulateur iPhone plante (et non l'application iPhone exécutée dans le simulateur), il y aura une entrée pour iPhoneSimulator.
Si l'application iPhone dans le simulateur plante, le journal des plantages apparaîtra avec le nom d'affichage de l'application.

Lorsque Xcode obtient les journaux de crash d'un appareil connecté, il les stocke dans des sous-dossiers de ~ / Library / Logs / CrashReporter / MobileDevice

— Vendeurs Walt
source

C'est plus d'un an plus tard, mais je vois que "l'application dans le simulateur" plante à ~ / Library / Logs / DiagnosticReports ... et cela ressemble à: MobileSafari_2013-03-21-155844_My-MacBook-Pro.crash

— Rob

0

Pour moi, c'était une expression que j'avais ajoutée à la fenêtre de surveillance du débogueur. Lorsqu'un point d'arrêt était atteint, la mauvaise expression provoquait une erreur de segmentation de XCode.

— pTymN
source