iOS
Debuggen van crashes

Informatie zoeken over een crash

Wanneer uw app crasht, zal Xcode de foutopsporing invoeren en u meer informatie over de crash tonen:

De belangrijkste onderdelen zijn:

De rode pijl

De rode pijl geeft aan welke coderegel is gecrasht en waarom deze is gecrasht.

De debugger-console

Veel crashes registreren meer informatie in de debugger-console. Het zou automatisch moeten verschijnen wanneer de app crasht, maar als deze er niet is, laat dan de debugger zien door de te selecteren in de rechterbovenhoek van Xcode en toon de console door op te klikken knop in de rechteronderhoek van het foutopsporingsprogramma.

Het stapelspoor

De stacktracering vermeldt de functies waaruit het programma kwam voordat het de gecrashte code bereikte.

Een deel van de stacktracering wordt links in het scherm weergegeven in de Debug Navigator en met de besturingselementen voor foutopsporing kunt u een stapelframe selecteren om in de debugger te bekijken:

Als u het bt commando invoert bij de (lldb) prompt in de debugger en op Return drukt, krijgt u een tekstuele weergave van de stacktracering die u kunt kopiëren en plakken:

(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

Foutopsporing SIGABRT en EXC_BAD_INSTRUCTION loopt vast

Een SIGABRT of een EXC_BAD_INSTRUCTION betekent meestal dat de app opzettelijk is gecrasht omdat een controle is mislukt. Deze zouden een bericht moeten loggen in de debugger-console met meer informatie; kijk daar voor meer informatie.

Veel SIGABRT 's worden veroorzaakt door niet-opgevangen Objective-C-uitzonderingen. Er zijn veel redenen waarom uitzonderingen kunnen worden gemaakt en ze zullen altijd veel nuttige informatie in de console opslaan.

• NSInvalidArgumentException , wat betekent dat de app een ongeldig argument heeft doorgegeven aan een methode
• NSRangeException , wat betekent dat de app probeerde toegang te krijgen tot een out-of-bounds index van een object zoals een NSArray of een NSString
• NSInternalInconsistencyException betekent een object dat zich in een onverwachte staat NSInternalInconsistencyException .
• NSUnknownKeyException betekent meestal dat u een slechte verbinding hebt in een XIB. Probeer enkele antwoorden op deze vraag .

Foutopsporing EXC_BAD_ACCESS

EXC_BAD_ACCESS betekent dat het proces op een ongeldige manier toegang probeerde te krijgen tot het geheugen, zoals een verwijzing naar een NULL aanwijzer of schrijven naar alleen-lezen geheugen. Dit is de moeilijkste vorm van crashen om te debuggen, omdat er meestal geen foutmelding is en sommige crashes erg moeilijk te reproduceren zijn en / of voorkomen in code die helemaal niets met het probleem te maken heeft. Deze fout is zeer zeldzaam in Swift, maar als het zich voordoet, kunt u vaak eenvoudiger vast te stellen fouten opsporen door compileroptimalisaties te verminderen.

De meeste EXC_BAD_ACCESS fouten worden veroorzaakt door te proberen een NULL aanwijzer te verwijderen. Als dit het geval is, is het adres in de rode pijl meestal een hexadecimaal nummer dat lager is dan een normaal geheugenadres, vaak 0x0 . Stel breekpunten in in het foutopsporingsprogramma of voeg af en toe printf / NSLog instructies toe om erachter te komen waarom die aanwijzer NULL .

Een EXC_BAD_ACCESS dat minder betrouwbaar voorkomt of helemaal geen zin heeft, kan het gevolg zijn van een probleem met geheugenbeheer. Veelvoorkomende problemen die dit kunnen veroorzaken, zijn:

• Gebruik van geheugen dat is toegewezen
• Probeert te schrijven voorbij het einde van een C-array of ander soort buffer
• Een aanwijzer gebruiken die niet is geïnitialiseerd

In het gedeelte Diagnostiek van de Scheme Editor bevat Xcode een paar handige hulpmiddelen om geheugenproblemen op te lossen:

Address Sanitizer voegt veel controles toe die de app stoppen wanneer zich geheugenproblemen voordoen en een nuttig foutbericht weergeven met precies wat er is gebeurd. Zombie Objects detecteert problemen met niet-toegewezen Objective-C-objecten, maar dit soort problemen met automatische referentietelling moet niet worden ingeschakeld.