App-Abstürze auf einem Mac sind in der Regel sehr selten. Wenn es jedoch passiert, möchten Sie diese Probleme vielleicht nachverfolgen. Und wenn Sie Entwickler sind, müssen Sie verstehen, warum Ihre App abstürzt. Hier erfahren Sie, wie Sie Absturzberichte in macOS nach codierter Sprache lesen und sortieren.
Schnelle Links
Absturzberichte öffnen
Wenn eine Anwendung auf Ihrem Mac abstürzt, wird automatisch ein Absturzbericht erstellt. Dies wird nach dem Absturz mit einem Warndialogfeld angezeigt, das besagt: „[Anwendung] wurde unerwartet gestoppt.“ Dieser Absturzbericht kann in diesem Fenster sofort gelesen werden, indem Sie auf die Schaltfläche „Bericht…“ klicken. Der Absturzbericht ist auch in der Konsolenanwendung zu finden.
1. Öffnen Sie die Konsolen-App, indem Sie „Console“ in Spotlight eingeben oder zu „Anwendung -> Dienstprogramme -> Console.app“ gehen.
2. Klicken Sie im linken Menü auf „Benutzerberichte“ und dann auf den Absturzbericht, den Sie anzeigen möchten. Alle diese Dateien enden mit „.crash“ und enthalten im Titel das Datum und die abgestürzte Anwendung. Einzelheiten zum Absturzbericht finden Sie im rechten Bereich.
Lesen Sie Absturzberichte für Mac OS
Gehen wir den Absturzbericht von oben nach unten durch.
Was ist kaputt?
Im ersten Teil des Absturzberichts erfahren Sie, ob ein Prozess oder eine Anwendung „kaputt“ ist. Der wichtigste Teil für eine Fehlerbehebung ist der Prozessname.
Prozess: aText [11473] Pfad: /Applications/aText.app/Contents/MacOS/aText Kennung: com.trankynam.aText Version: 2.19 (62) Code-Typ: X86-64 (Nativ) Übergeordneter Prozess: ??? [1] Verantwortlich: aText [11473] Benutzer-ID: 501
Wann ist die Störung aufgetreten?
Der zweite Teil sagt uns, wann der Fehler aufgetreten ist. Es enthält auch einige Informationen zu Ihrem System.
Datum/Uhrzeit: 15.03.2018 00:58:10.552 -0400 Betriebssystemversion: Mac OS 630000 Sekunden Systemintegritätsschutz: aktiviert
Was hat die Störung verursacht?
Der nächste Teil ist der am meisten beleuchtete. Der „Ausnahmetyp“, den die Anwendung auslöst, sagt uns, was den Absturz verursacht hat. Außerdem wird protokolliert und gemeldet, welcher Thread abgestürzt ist: in diesem Fall Thread 0.
Abgestürzter Thread: 0 Dispatch-Warteschlange: com.apple.main-thread Ausnahmetyp: EXC_BAD_ACCESS (SIGSEGV) Ausnahmecodes: KERN_INVALID_ADDRESS bei 0x000040dedeadbec0 Ausnahmehinweis: EXC_CORPSE_NOTIFY Beendigungssignal: Segmentierungsfehler: 11 Beendigungsgrund: Namespace SIGNAL, Code 0xb Beendender Prozess: exc handler [0]
Apple-Listen Einige häufige Arten von Ausnahmen In seiner technischen Dokumentation:
Schlechter Speicherzugriff (EXC_BAD_ACCESS / SIGSEGV / SIGBUS) – Das Programm versucht, falsch auf den Speicher zuzugreifen oder eine ungültige Adresse zu verwenden. Mit Code, der das Speicherproblem erklärt.
abnormaler Exit (EXC_CRASH / SIGABRT) – abnormaler Exit, normalerweise durch eine nicht abgefangene C++-Ausnahme und einen Aufruf von abort()
Trace Trap (EXC_BREAKPOINT / SIGTRAP) – Wie SIGABRT, aber diese Beendigung gibt dem angeschlossenen Debugger die Möglichkeit, den Prozess an einem Haltepunkt zu unterbrechen und den Fehler zu verfolgen.
Unzulässige Anweisung (EXC_BAD_INSTRUCTION / SIGILL) – Die Verarbeitung hat eine Verarbeitung ausgegeben, die nicht verstanden wurde oder nicht verarbeitet werden konnte.
Beenden (SIGQUIT) – Der Prozess wurde von einem anderen Prozess mit ausreichenden Berechtigungen beendet. Normalerweise beendet der Überwachungsprozess den Kunstfehlervorgang.
TERMINATE (SIGKILL) – Der Prozess wurde auf Anforderung des Systems beendet. Zur Erläuterung der Ausnahme wird ein Exit-Code angehängt.
Wie wir dem Absturzbericht entnehmen können, hat die Anwendung versucht, auf nicht isolierten Speicher zuzugreifen. Dies ist auf einen Programmierfehler in der Anwendung oder eine ungewöhnliche Benutzerbedingung zurückzuführen, die dazu führt, dass die Anwendung den Speicher falsch zuordnet.
Was verursacht die Störung?
Als nächstes sehen wir eine umgekehrt chronologische Liste dessen, was zu einem Absturz führt. Diese sind nach Thread sortiert, beginnend mit Thread 0.
Dieser Bericht besteht aus vier Spalten. Der erste meldet die Ereignisnummer in umgekehrter chronologischer Reihenfolge, beginnend bei 0. Der zweite ist die Prozess-ID. Der dritte ist die Adresse des Prozesses im Speicher. Der vierte ist der Name der Programmaufgabe.
Diese „Regression“ kann etwas verwirrend sein. Es ist „symbolisch“, was bedeutet, dass einige Speicheradressen durch die Namen von Funktionen oder Anwendungsaufgaben ersetzt wurden. Manchmal ist dies nicht vollständig möglich, sodass unlesbare Speicheradressen im gesamten Bericht verstreut bleiben.
Wir sehen dies im Absturzbericht oben: com.trankynam.aText ist nicht symbolisch. Selbst bei vollständiger Kodierung kann das Backend schwer lesbar sein. Softwareentwickler fügen manchmal hilfreiche Hinweise zu Anwendungsaufgaben und -ereignissen hinzu. In anderen Fällen handelt es sich um verschlüsselte Adressen oder digitalen Code. Wenn Sie die Symbolik verstehen, können Sie möglicherweise verstehen, was passiert. Sie müssen die Anwendung jedoch so weit wie möglich selbst programmieren, um den Backtrace zu verstehen.
Fazit: Ist das hilfreich?
Wenn Sie Softwareentwickler sind, ist es wichtig, Absturzberichte zu lesen. Dies hilft Ihnen zu verstehen, welcher Teil Ihrer Anwendung Probleme verursacht und warum. Wenn Sie ein Benutzer sind, sind sie nicht nützlich. Wenn Sie jedoch anhaltende Abstürze haben, können Absturzberichte Ihnen dabei helfen, das Problem zu beheben oder mit einem Entwickler zusammenzuarbeiten, um das Problem zu beheben. Möglicherweise können Sie den Fehlercode über Google hilfreich beheben lassen oder ihn mit den richtigen Informationen an den technischen Support senden. Wenn Sie drastische Details wünschen, können Sie alles darüber unter lesen Technischer Hinweis von Apple zu Abstürzen.
