App-Abstürze auf dem Mac sind in der Regel ziemlich selten. Aber wenn sie passieren, möchten Sie möglicherweise ihre Ursache verfolgen. Und wenn Sie Entwickler sind, müssen Sie verstehen, warum Ihre App abstürzt. Hier erfahren Sie, wie Sie macOS-Absturzberichte lesen und die kryptische Sprache sortieren können.

Crashberichte öffnen

Wenn eine App auf Ihrem Mac abstürzt, wird automatisch ein Absturzbericht erstellt. Nach dem Absturz wird dies mit einem Warndialog angezeigt, der sagt: " [App] wurde unerwartet beendet. "Dieser Absturzbericht kann sofort in diesem Fenster gelesen werden, indem Sie auf die Schaltfläche" Bericht ... "klicken. Der Absturzbericht kann auch in der Konsolen-App gefunden werden.

1. Öffnen Sie die Konsolenanwendung, indem Sie "Konsole" in Spotlight eingeben oder zu "Anwendung -> Dienstprogramme -> Konsole.app" navigieren.

2. Klicken Sie im linken Menü auf "Benutzerberichte" und dann auf den gewünschten Absturzbericht. Alle diese Dateien enden in ".crash" und enthalten das Datum und die abgestürzte Anwendung im Titel. Die Details zum Absturzbericht finden Sie im rechten Bereich.

Mac OS Crash Reports lesen

Lassen Sie uns den Absturzbericht von oben nach unten durchgehen.

Was ist abgestürzt?

Der erste Teil des Absturzberichtes sagt Ihnen, welcher "Prozess" oder welche Anwendung abgestürzt ist. Der wichtigste Teil für die durchschnittliche Problembehandlung ist der Prozessname.

 Prozess: aText [11473] Pfad: /Applications/aText.app/Contents/MacOS/aText Kennung: com.trankynam.aText Version: 2.19 (62) Codetyp: X86-64 (nativ) Übergeordneter Prozess: ??? [1] Verantwortlich: aText [11473] Benutzer-ID: 501

Wann ist es abgestürzt?

Der zweite Teil sagt uns, wann der Absturz aufgetreten ist. Es bietet auch ein wenig Informationen über Ihr System.

 Datum / Uhrzeit: 2018-03-15 00: 58: 10.552 -0400 OS-Version: Mac OS X 10.12.6 (16G1036) Berichtsversion: 12 Anonyme UUID: 6C985CFD-6975-3F30-50EB-0713315F5090 Zeit seit dem Start: 630000 Sekunden Systemintegritätsschutz: aktiviert

Was hat den Absturz verursacht?

Der nächste Teil ist der aufschlussreichste. Der "Ausnahmetyp", der von der Anwendung bereitgestellt wird, sagt uns, was den Absturz verursacht hat. Das Protokoll meldet auch, welcher Thread abgestürzt ist: in diesem Fall Thread 0.

 Abgestürzter Thread: 0 Versandwarteschlange: com.apple.main-thread Ausnahmetyp: EXC_BAD_ACCESS (SIGSEGV) Ausnahmecodes: KERN_INVALID_ADDRESS bei 0x000040dedeadbec0 Ausnahme Hinweis: EXC_CORPSE_NOTIFY Terminierungssignal: Segmentationsfehler: 11 Terminierungsgrund: Namespace SIGNAL, Code 0xb Abschlussvorgang: exc Handler [0]

Apple listet einige häufige Ausnahmearten in ihrer technischen Dokumentation auf:

  • Schlechter Speicherzugriff ( EXC_BAD_ACCESS / SIGSEGV / SIGBUS ) - Das Programm versucht, falsch oder mit einer ungültigen Adresse auf den Speicher zuzugreifen. Angehängt mit einem Code, der das Speicherproblem erklärt.
  • Abnormal Exit ( EXC_CRASH / SIGABRT ) - abnormaler Ausgang, der normalerweise von einer nicht abgefangenen C ++ - Ausnahme SIGABRT, und Aufrufe von abort()
  • Trace Trap ( EXC_BREAKPOINT / SIGTRAP ) - wie SIGABRT, aber dieser Exit gibt dem angehängten Debugger die Möglichkeit, den Prozess an einem Breakpoint zu unterbrechen und den Fehler zu verfolgen.
  • Illegal Instruction ( EXC_BAD_INSTRUCTION / SIGILL ) - der Bearbeitete hat eine Anweisung ausgegeben, die nicht verstanden wurde oder nicht verarbeitet werden konnte.
  • Quit ( SIGQUIT ) - der Prozess wurde von einem anderen Prozess mit ausreichenden Privilegien beendet. In der Regel beendet ein Watchdog-Prozess einen fehlerhaften Prozess.
  • Getötet ( SIGKILL ) - der Vorgang wurde auf Anforderung des Systems beendet. Ein Beendigungscode wird hinzugefügt, um die Ausnahme zu erklären.

Wie wir in unserem Absturzbericht sehen können, hat die Anwendung versucht, auf nicht zugeordneten Speicher zuzugreifen. Dies liegt an einem Programmierfehler in der Anwendung oder an einem ungewöhnlichen Benutzerzustand, der dazu führt, dass die Anwendung den Speicher falsch abbildet.

Was führte zum Absturz?

Danach sehen wir eine umgekehrte chronologische Liste dessen, was zu dem Absturz geführt hat. Diese sind nach dem Thread sortiert, beginnend mit Thread 0.

Dieser Bericht enthält vier Spalten. Der erste gibt die Nummer des Ereignisses in umgekehrter chronologischer Reihenfolge an, beginnend bei 0. Die Sekunde ist die Kennung des Prozesses. Die dritte ist die Adresse des Prozesses im Speicher. Der vierte ist der Name der Programmaufgabe.

Dieses "Backtrace" kann etwas verwirrend sein. Es ist "symbolisiert", was bedeutet, dass einige der Speicheradressen durch Funktionsnamen oder Anwendungsaufgaben ersetzt wurden. Manchmal kann dies nicht vollständig ausgeführt werden, wodurch unlesbare Speicheradressen im Bericht verstreut bleiben.

Das sehen wir im obigen com.trankynam.aText : com.trankynam.aText ist nicht symbolisiert. Selbst bei vollständiger Symbolisierung kann es schwierig sein, das Backtrace zu lesen. Manchmal enthalten Entwickler nützliche Hinweise zu Anwendungsaufgaben und Ereignissen. Zu anderen Zeiten sind es kryptische Titel oder Zahlencodes. Wenn Sie die Symbolik verstehen können, können Sie möglicherweise verstehen, was passiert. Es ist aber auch möglich, dass Sie die Anwendung selbst codiert haben müssen, um den Backtrace zu verstehen.

Fazit: Ist das nützlich?

Wenn Sie Entwickler sind, ist das Lesen von Absturzberichten unerlässlich. Es hilft Ihnen zu verstehen, welcher Teil Ihrer Anwendung abstürzt und warum. Wenn Sie ein Benutzer sind, sind sie nicht so hilfreich. Wenn Sie jedoch einen anhaltenden Absturz haben, können die Absturzberichte Ihnen helfen, das Problem zu beheben oder mit dem Entwickler zu arbeiten, um das Problem zu beheben. Sie erhalten möglicherweise einen nützlichen Fehlercode für Google oder können technischen Support mit den richtigen Informationen bereitstellen. Wenn Sie die blutigen Details wollen, können Sie alles darüber in Apples technischer Notiz zu Abstürzen lesen.