iOS
Debuggen von Abstürzen

Informationen zu einem Absturz suchen

Wenn Ihre App abstürzt, öffnet Xcode den Debugger und zeigt Ihnen weitere Informationen zum Absturz:

Die wichtigsten Teile sind:

Der rote Pfeil

Der rote Pfeil zeigt an, welche Codezeile abgestürzt ist und warum der Code abgestürzt ist.

Die Debugger-Konsole

Viele Abstürze protokollieren weitere Informationen in der Debugger-Konsole. Es sollte automatisch angezeigt werden, wenn die App abstürzt. Wenn dies nicht der Fall ist, zeigen Sie den Debugger an, indem Sie die Option auswählen in der oberen rechten Ecke von Xcode, und zeigen Sie die Konsole an, indem Sie auf klicken Schaltfläche in der rechten unteren Ecke des Debuggers.

Die Stapelverfolgung

Der Stack-Trace listet die Funktionen auf, aus denen das Programm kam, bevor es zu dem abgestürzten Code kam.

Ein Teil der Stack-Ablaufverfolgung wird im Debug-Navigator auf der linken Seite des Bildschirms angezeigt. Mit den Steuerelementen des Debuggers können Sie einen Stack-Frame auswählen, der im Debugger angezeigt werden soll:

Wenn Sie die Eingabe bt Befehl an der (lldb) prompt im Debugger und drücken Sie die Eingabetaste, werden Sie eine Textdarstellung der Stack - Trace, die Sie kopieren und einfügen können:

(lldb) bt
* thread #1: tid = 0x3aaec5, 0x00007fff91055f06 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x00007fff91055f06 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x000000010008142d libsystem_pthread.dylib`pthread_kill + 90
    frame #2: 0x00007fff96dc76e7 libsystem_c.dylib`abort + 129
    frame #3: 0x00007fff8973bf81 libc++abi.dylib`abort_message + 257
    frame #4: 0x00007fff89761a47 libc++abi.dylib`default_terminate_handler() + 267
    frame #5: 0x00007fff94f636ae libobjc.A.dylib`_objc_terminate() + 103
    frame #6: 0x00007fff8975f19e libc++abi.dylib`std::__terminate(void (*)()) + 8
    frame #7: 0x00007fff8975ec12 libc++abi.dylib`__cxa_throw + 121
    frame #8: 0x00007fff94f6108c libobjc.A.dylib`objc_exception_throw + 318
    frame #9: 0x00007fff8d067372 CoreFoundation`-[__NSPlaceholderArray initWithObjects:count:] + 290
    frame #10: 0x00007fff8d0eaa1f CoreFoundation`+[NSArray arrayWithObject:] + 47
  * frame #11: 0x0000000100001b54 test`main(argc=1, argv=0x00007fff5fbff808) + 68 at main.m:15
    frame #12: 0x00007fff8bea05ad libdyld.dylib`start + 1
    frame #13: 0x00007fff8bea05ad libdyld.dylib`start + 1

Das Debuggen von SIGABRT und EXC_BAD_INSTRUCTION stürzt ab

Ein SIGABRT oder eine EXC_BAD_INSTRUCTION bedeutet normalerweise, dass die App absichtlich abgestürzt ist, da einige Prüfungen fehlgeschlagen sind. Diese sollten eine Nachricht mit weiteren Informationen an die Debugger-Konsole protokollieren. Weitere Informationen finden Sie dort.

Viele SIGABRT werden durch nicht SIGABRT Objective-C-Ausnahmen verursacht. Es gibt viele Gründe, aus denen Ausnahmen ausgelöst werden können, und es werden immer viele hilfreiche Informationen auf der Konsole protokolliert.

• NSInvalidArgumentException , was bedeutet, dass die App ein ungültiges Argument an eine Methode übergeben hat
• NSRangeException , was bedeutet, dass die App versucht hat, auf einen Index außerhalb des NSArray NSString eines Objekts NSArray NSString
• NSInternalInconsistencyException bedeutet, dass ein Objekt festgestellt hat, dass es sich in einem unerwarteten Zustand NSInternalInconsistencyException .
• NSUnknownKeyException bedeutet normalerweise, dass in einer XIB eine schlechte Verbindung besteht. Versuchen Sie einige Antworten auf diese Frage .

Debuggen von EXC_BAD_ACCESS

EXC_BAD_ACCESS bedeutet, dass der Prozess versucht hat, auf einen ungültigen Zugriff auf den Speicher zuzugreifen, z. B. der Deferenzierung eines NULL Zeigers oder das Schreiben in den Nur-Lese-Speicher. Dies ist die schwierigste Art des Absturzes beim Debuggen, da normalerweise keine Fehlermeldung angezeigt wird und einige Abstürze sehr schwer reproduzierbar sind und / oder in Code auftreten, der nicht mit dem Problem zusammenhängt. Dieser Fehler tritt in Swift sehr selten auf. Wenn er jedoch auftritt, können Abstürze durch das Reduzieren der Compiler-Optimierungen oft leichter zu debuggen sein.

Die meisten EXC_BAD_ACCESS Fehler werden durch den Versuch verursacht, einen NULL Zeiger zu dereferenzieren. Wenn dies der Fall ist, ist die im roten Pfeil angegebene Adresse normalerweise eine Hexadezimalzahl, die niedriger als eine normale Speicheradresse ist, häufig 0x0 . Setzen Sie Haltepunkte im Debugger oder fügen Sie gelegentlich printf / NSLog Anweisungen hinzu, um herauszufinden, warum der Zeiger NULL .

Ein EXC_BAD_ACCESS , der weniger zuverlässig auftritt oder überhaupt keinen Sinn EXC_BAD_ACCESS , könnte das Ergebnis eines Speicherverwaltungsproblems sein. Häufige Probleme, die dies verursachen können, sind:

• Verwendung von Speicher, der freigegeben wurde
• Der Versuch, über das Ende eines C-Arrays oder eines anderen Puffers zu schreiben
• Verwendung eines Zeigers, der nicht initialisiert wurde

Xcode enthält im Diagnoseabschnitt des Schema-Editors einige nützliche Tools zum Beheben von Speicherproblemen:

Der Address Sanitizer fügt viele Überprüfungen hinzu, mit denen die App angehalten wird, wenn Speicherprobleme auftreten, und eine hilfreiche Fehlermeldung mit genauen Angaben zu den Vorgängen angezeigt. Zombie Objects erkennt Probleme mit freigewiesenen Objective-C-Objekten, aber diese Art von Problemen sollte bei aktivierter automatischer Referenzzählung nicht auftreten.