iOS
Il debug si blocca

Trovare informazioni su un incidente

Quando l'app si arresta in modo anomalo, Xcode entra nel debugger e mostra ulteriori informazioni sullo schianto:

Le parti più importanti sono:

La freccia rossa

La freccia rossa mostra quale linea di codice si è bloccata e perché si è bloccata.

La console del debugger

Molti arresti anomali registrano più informazioni sulla console del debugger. Dovrebbe apparire automaticamente quando l'app si arresta in modo anomalo, ma se non c'è, mostra il debugger selezionando il pulsante nell'angolo in alto a destra di Xcode e mostra la console facendo clic su pulsante nell'angolo in basso a destra del debugger.

La traccia dello stack

La traccia dello stack elenca le funzioni del programma prima che arrivasse al codice che si arrestava in modo anomalo.

Una parte della traccia dello stack viene visualizzata nel Navigatore di debug sulla sinistra dello schermo, mentre i controlli del debugger consentono di selezionare uno stack frame da visualizzare nel debugger:

Se si immette il bt comando al (lldb) pronta nel debugger e premere invio, si otterrà una rappresentazione testuale della traccia dello stack che è possibile copiare e incollare:

(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

Debug di SIGABRT e EXC_BAD_INSTRUCTION arresti anomali

Un SIGABRT o EXC_BAD_INSTRUCTION di solito significa che l'app si è bloccata intenzionalmente perché alcuni controlli non sono riusciti. Questi dovrebbero registrare un messaggio nella console del debugger con più informazioni; controllare lì per ulteriori informazioni.

Molti SIGABRT sono causati da eccezioni Objective-C non catturate. Ci sono molti motivi per cui possono essere lanciate eccezioni e registreranno sempre molte informazioni utili alla console.

• NSInvalidArgumentException , che significa che l'app ha passato un argomento non valido a un metodo
• NSRangeException , che significa che l'app ha provato ad accedere a un indice fuori limite di un oggetto come un NSArray o una NSString
• NSInternalInconsistencyException indica che un oggetto ha scoperto che si trovava in uno stato imprevisto.
• NSUnknownKeyException solito significa che hai una cattiva connessione in un XIB. Prova alcune delle risposte a questa domanda .

Debug di EXC_BAD_ACCESS

EXC_BAD_ACCESS significa che il processo ha tentato di accedere alla memoria in modo non valido, come il dereferenziamento di un puntatore NULL o la scrittura nella memoria di sola lettura. Questo è il tipo più difficile di arresto anomalo del debug, perché di solito non ha un messaggio di errore e alcuni arresti anomali possono essere molto difficili da riprodurre e / o verificarsi in codice completamente estraneo al problema. Questo errore è molto raro in Swift, ma se si verifica, spesso è possibile ottenere arresti più facili da debug riducendo le ottimizzazioni del compilatore.

La maggior parte EXC_BAD_ACCESS errori EXC_BAD_ACCESS sono causati dal tentativo di dereferenziare un puntatore NULL . Se questo è il caso, l'indirizzo elencato nella freccia rossa sarà solitamente un numero esadecimale che è inferiore a un normale indirizzo di memoria, spesso 0x0 . Impostare i punti di interruzione nel debugger o aggiungere istruzioni printf / NSLog occasionali per scoprire perché il puntatore è NULL .

Un EXC_BAD_ACCESS che si verifica in modo meno affidabile o non ha alcun senso potrebbe essere il risultato di un problema di gestione della memoria. I problemi comuni che possono causare questo sono:

• Usando la memoria che è stata deallocata
• Cercando di scrivere oltre la fine di un array C o di un altro tipo di buffer
• Utilizzando un puntatore che non è stato inizializzato

Nella sezione Diagnostics dell'Editor schema, Xcode include alcuni strumenti utili per aiutare a risolvere i problemi di memoria:

Address Sanitizer aggiunge molti controlli che interrompono l'app ogni volta che si verificano problemi di memoria e forniscono un utile messaggio di errore che descrive esattamente cosa è successo. Zombie Objects rileva problemi con oggetti Objective-C deallocati, ma non si dovrebbe avere questo tipo di problemi con il conteggio dei riferimenti automatico attivato.