iOS
Debugging Crash

Hitta information om en krasch

När din app kraschar kommer Xcode in i felsökaren och visar dig mer information om kraschen:

De viktigaste delarna är:

Den röda pilen

Den röda pilen visar vilken kodrad som kraschade och varför den kraschade.

Felsökningskonsolen

Många kraschar loggar mer information till felsökningskonsolen. Den ska automatiskt visas när appen kraschar, men om den inte är där, visa felsökaren genom att välja -knappen i det övre högra hörnet av Xcode och visa konsolen genom att klicka på i nedre högra hörnet av felsökaren.

Stacken spår

Stack-spåret listar de funktioner programmet kom från innan det kom till koden som kraschade.

En del av stackspåret visas i Debug Navigator till vänster på skärmen, och felsökningskontrollerna låter dig välja en stapelram som ska visas i felsökaren:

Om du anger kommandot bt vid prompten (lldb) i felsökaren och trycker på retur , får du en (lldb) som du kan kopiera och klistra in:

(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

Felsökning SIGABRT och EXC_BAD_INSTRUCTION kraschar

En SIGABRT eller en EXC_BAD_INSTRUCTION betyder vanligtvis att appen kraschade själv med avsikt eftersom någon kontroll misslyckades. Dessa bör logga ett meddelande till felsökningskonsolen med mer information. kolla där för mer information.

Många SIGABRT er orsakas av undantagna Objekt-C-undantag. Det finns många orsaker till att undantag kan kastas, och de loggar alltid mycket användbar information till konsolen.

• NSInvalidArgumentException , vilket innebär att appen överförde ett ogiltigt argument till en metod
• NSRangeException , vilket innebär att appen försökte komma åt ett index utanför gränserna för ett objekt som en NSArray eller en NSString
• NSInternalInconsistencyException betyder att ett objekt upptäckte att det var i ett oväntat tillstånd.
• NSUnknownKeyException betyder vanligtvis att du har en dålig anslutning i en XIB. Prova några av svaren på den här frågan .

Felsökning EXC_BAD_ACCESS

EXC_BAD_ACCESS innebär att processen försökte komma åt minnet på ett ogiltigt sätt, som att hämta en NULL pekare eller skriva till skrivskyddat minne. Det här är den svåraste typen av krasch att felsöka, eftersom det vanligtvis inte har något felmeddelande, och vissa kraschar kan vara mycket svåra att reproducera och / eller uppstå i kod helt kopplad till problemet. Det här felet är mycket sällsynt i Swift, men om det inträffar kan du ofta få lättare att felsöka kraschar genom att minska kompilatoroptimeringarna.

De flesta EXC_BAD_ACCESS fel orsakas av att försöka eliminera en NULL pekare. Om detta är fallet kommer adressen som anges i den röda pilen vanligtvis att vara ett hexadecimalt antal som är lägre än en normal minnesadress, ofta 0x0 . Ställ in brytpunkter i felsökaren eller lägg tillfälliga printf / NSLog uttalanden för att ta reda på varför pekaren är NULL .

Ett EXC_BAD_ACCESS som inträffar mindre pålitligt eller som inte alls är vettigt kan vara resultatet av ett minneshanteringsproblem. Vanliga problem som kan orsaka detta är:

• Använda minne som har omlokaliserats
• Försöker skriva förbi slutet på en C-matris eller annan typ av buffert
• Med hjälp av en pekare som inte har initialiserats

I diagnosavsnittet i Scheme Editor innehåller Xcode några användbara verktyg som hjälper till att felsöka minnesproblem:

Address Sanitizer lägger till massor av kontroller som kommer att stoppa appen när minnesproblem uppstår och ger ett användbart felmeddelande med exakt vad som hände. Zombie Objects upptäcker problem med omlokaliserade Objekt-C-objekt, men du bör inte få sådana problem med automatisk referensräkning aktiverad.