Interpretare i Crash Logs

Sebbene MacOsX metta sempre a disposizione, sia in caso di crash di applicazione che di kernel panic, esaurienti dettagli tecnici sulle cause del malfunzionamento, è anche vero che per un utente che non possegga specifiche conoscenze è solitamente difficile riuscire ad interpretare tali informazioni.
Anche la ricerca in rete non è esauriente sotto questo profilo, limitandosi a generiche indicazioni oppure a spiegazioni troppo tecniche per essere comprese da utenti inesperti, quasi sempre in inglese, oltretutto.

Comincio col tradurre liberamente da un articolo non recentissimo, ma che mi pare interessante per approcciare questa problematica, e vi solleciterei - con il tempo - a postare in questo topic tutte le soluzioni e le informazioni interessanti che potrete reperire, in modo che possa essere di riferimento per chi ne ha bisogno, e anche di utilità per chi è comunque interessato all'argomento.

Il primo consiglio che viene fornito è di creare un utente supplementare che sarà utilizzato solo in caso di problemi, per verificarne le cause. E' importante mantenere il software di questo utente aggiornato, ma senza aggiungere applicazioni di terze parti, add-ons, input managers, ecc. Quando si presenta il problema sull'utenza principale, sarà possibile tentare di ricreare il problema con l'utenza secondaria, permettendoci cosi di determinare se il crash sia dovuto a file corrotti nelle librerie dell'utente principale.

Spesso la difficoltà di individuare le cause di un crash è determinata dal multi-tasking, che permette all'utente l'uso intensivo, anche per parecchie ore, di un certo numero di applicazioni. Ecco che il crash log, ereditato da Unix, fornirà - a chi è in grado di interpretarlo - tutte le informazioni necessarie per determinare il problema.
Perlopiu' un crash log è collocato in una cartella contenuta nella Libreria della home directory dell'utente, il cui percorso è:

utente/Libreria/Logs/CrashReporter

Secondo Apple, ci sono speciali circostanze per le quali i Crash Logs saranno invece registrati in :

Hd/Libreria/Logs/CrashReporter/NomeProgramma.crash.log

Questo nel caso specifico che si verifichi una di queste circostanze: Che non possa essere determinato il titolare del processo che ha fallito, oppure che il processo fallito fosse attribuito all'utente root, o infine che la home directory dell'utente non fosse per qualche motivo scrivibile.

E' possibile accedere ai Crash Logs usando la Console, che si trova in Applicazioni/Utilities dell'hard disk. Le informazioni contenute nei crash Logs sono destinate agli sviluppatori che dovranno mettere a punto il sistema e migliorarlo, ecco perchè appaiono cosi difficili da interpretare per un utente normale.
Vediamo pero' quale tipo di indicazioni possiamo facilmente desumere dal Crash Log.

Le prime righe di un Crash Log contengono la data e l'ora del crash, cosi come le informazioni relative alla versione del sistema operativo. Inoltre apparirà il build number, che specificamente indica che tipo di hardware viene impiegato dal nostro Mac (e che potrebbe differire a parità di sistema operativo impiegato).

Prendiamo ad esempio il crash Log di Ric, e vediamo che il report indica:

Citazione:
Date/Time: 2009-02-10 00:43:33.997 +0100
OS Version: Mac OS X 10.5.6 (9G55)
Report Version: 6

Il segmento successivo (che nel caso di Ric appare invece inserito per primo) identifica il processo crashato, il processo parente, e il numero di versione. Queste informazioni possono rivelarsi utili nel caso che non siate sicuri di quale applicazione abbia portato al crash, perchè a volte succede che il processo in crash è stato "chiamato" in causa da un ulteriore processo che se ne assume, quindi, la responsabilità.
Nel caso di Ric leggiamo:

Citazione:
Process: Safari [950]
Path: /Applications/Safari.app/Contents/MacOS/Safari
Identifier: com.apple.Safari
Version: 3.2.1 (5525.27.1)
Build Info: WebBrowser-55252701~1
Code Type: PPC (Native)
Parent Process: launchd [106]

Il prossimo blocco ci informa a proposito del tipo di crash occorso. Si tratta di informazioni troppo generiche per aiutare un utente ad individuare il problema, spesso ci si chiede se siano attualmente di aiuto anche per gli sviluppatori. Apple ha comunque identificato le quattro eccezioni piu' comuni, che vengono cosi riassunte:

Citazione:
KERN_INVALID_ADDRESS
Il processo in questione tenta di utilizzare una memoria non mappata. Questo errore puo' essere causato sia da dati sia da un'istruzione fornita dall'utente.

KERN_PROTECTION_FAILURE
Questa è sempre una issue relativa a dati. Il processo in esame sta tentando di scrivere dati in un'area di memoria che è destinata alla sola lettura.

BAD_INSTRUCTION
C'è qualcosa di errato con l'istruzione che un processo sta tentando di eseguire.

ARITHMETIC/EXC_I386_DIV
Un errore che si verifica sui Mac Intel quando il processo in questione tenta di dividere un integrale per zero.

Inoltre troviamo a seguire il thread che ha crashato cio' che stava succedendo immediatamente prima del crash.
La prima colonna di questa sezione indica l'ordine delle azioni compiute, elencate in ordine inverso cronologicamente, per cui la zero sarà la prima della lista e la piu' recente.
La seconda colonna indica la libreria che contiene il codice per quella linea.
La terza colonna è un indirizzo counter del programma.
La quarta colonna indica il nome della funzione eseguita al momento del crash.
Per Ric quindi troviamo queste indicazioni:

Citazione:
Crashed Thread: 3

Cercheremo quindi a seguire il thread numero tre con le ulteriori informazioni:

Citazione:
Thread 3 Crashed:
0 libSystem.B.dylib 0xffff87f4 __memcpy + 84 (cpu_capabilities.h:237)
1 com.apple.Safari 0x0011996c 0x1000 + 1149292
2 com.apple.Safari 0x0012149c 0x1000 + 1180828
3 com.apple.Safari 0x0010e104 0x1000 + 1102084
4 com.apple.CoreFoundation 0x92bfc9d8 CFRunLoopRunSpecific + 2968
5 com.apple.Safari 0x001208e8 0x1000 + 1177832
6 com.apple.Safari 0x0012099c 0x1000 + 1178012
7 libSystem.B.dylib 0x96b1c024 _pthread_start + 316

Questo segmento puo' svilupparsi per molte righe, che - sebbene perolopiu' inintelligibili - possono ad un attento esame provvedere indizi sufficienti ad interpretare cio' che l'applicazione stava facendo al momento del crash.
Se si è sufficientemente fortunati, questo segmento potrebbe contenere indicazioni e nomi in qualche maniera descrittivi del problema.

In questo specifico caso sembrerebbe che utilizzando Safari si sia veificato un impegno eccessivo di CPU. Questo potrà determinarlo solo Ric ricordando esattamente quali siti e quali attività stesse svolgendo con Safari in quel momento.
Queste informazioni sono importanti anche quando si decida di segnalare agli sviluppatori il crash, per ottenere ulteriori spiegazioni e indirizzarli meglio a fissare l'inconveniente.

Ora è tempo di tentare di risolvere il problema, non importa quanto esso possa apparire complesso. Si tratta in fondo di rispondere a quattro domande basiche.

- che tipo di problema sto incontrando?
- quando si è verificato il problema?
- quali appaiono essere i fattori che hanno scatenato il problema?
- come risolvere il problema?

La prima domanda ci indirizza a distinguere se si tratta di un kernel panic, che coinvolge l'intero sistema, o un crash di applicazione, che usualmente coinvolge un unico programma.
Kernel panic sono spesso il risultato di problemi hardware o con le estensioni kernel. Non necessariamente si tratta di hardware danneggiato irrimediabilmente, perchè spesso un kernel panic puo' essere relativo a carte memoria o grafiche non propriamente inserite nei rispettivi slots. Oppure puo' essere conseguente ad un recente aggiornamento di componenti, nel qual caso è opportuno verificare che l'installazione sia avvenuta correttamente.

I crash relativi alle Applicazioni invece riguardano un programma specifico, lasciando il resto del sistema intatto. E' necessario ricordare quali applicazioni fossero in esecuzione al momento del crash e quali attività si stessero svolgendo, cosi da poter ricreare esattamente la situazione e verificare se, alle stesse condizioni, il crash si ripeta.

Arrivati a questo punto, dovreste avere una potenziale idea di quale area esaminare per risolvere il problema, provando a semplificare il numero di issues che dovranno essere investigate.
Se sospettate che sia un problema di hardware, controllate i cavi di alimentazione, scollegate le periferiche e ricollegatele solamente una alla volta.

Se invece state cercando di risolvere un problema di software, provate a loggarvi con l'utente alternativo che avete creato per questa eventualità.
Se il problema non si ripresenta con tale utenza, saranno i files contenuti nella libreria del vostro utente abituale a dover essere esaminati.
Nel caso in cui il problema si presenti con entrambi gli utenti, riavviate tenendo premuto Shift. Questo forza il sistema a riavviare con unicamente le estensioni kernel assolutamente necessarie per il sistema e potrebbe eliminare il problema, se comune ad entrambi gli accounts.

Ci sono altre abbreviazioni da tastiera utilizzabili sia in caso di problemi, sia quotidianamente per le usuali applicazioni. In questa lista troverete quanto vi occorre.

In conclusione, si raccomanda di seguire tre facili indicazioni:
- per prima cosa controllate l'ovvio (un esempio sono i cavi di alimentazione)
- secondariamente dedicate la vostra attenzione alle cose piu' semplici.
Nella mia esperienza, quando ebbi problemi relativi alla memoria, dovetti aprire piu' volte il case per controllare se i chips in questione fossero stati installati in maniera adeguata. In una di queste sequenze, mi capito' di non udire il chime di avvio. Il chime (il BOING del Mac ndt )viene emesso quando il MAC passa il POST, cioè il test di accensione. Se il MAC fallisce il POST, c'è verosimilmente in corso una issue di hardware che necessita di essere risolta e piu' genericamente indica che c'è qualche pezzo interno non appropriatamente connesso o che ha fallito il test.
- in terza istanza, provate a ripetere l'operazione che causa il crash in un modo alternativo. Ad esempio, se state tentando di copiare un testo utilizzando le abbreviazioni da tastiera, provate a fare la stessa cosa con il comando da Menu. A seconda che il crash si ripeta o meno, avrete un ulteriore elemento utile per investigare il problema e sottoporlo all'attenzione di chi è competente a risolverlo.

Articolo liberamente tradotto ed adattato da http://www.atpm.com/12.10/crashes.shtml

Tutorial di Pippi

Discussione sul Forum