Leggere i report

Un report di Valgrind è composto da tre parti:

• Il prefisso dell'ID del processo su ogni riga
• Uno o più blocchi di errore nel momento in cui si verificano
• Un HEAP and LEAK SUMMARY finale all'uscita

Imparare a leggere ogni parte trasforma un muro di testo in un elenco preciso di attività.

Ogni riga di Valgrind inizia con ==PID==, per esempio ==12345==.

Questo è l'ID del processo, non fa parte dell'output del programma. Le permette di distinguere i messaggi di Valgrind dall'output di printf del programma quando entrambi condividono il terminale.

Ecco un vero blocco relativo a una scrittura non valida:

==12345== Invalid write of size 4
==12345== at 0x4005A1: main (prog.c:6)
==12345== Address 0x520304c is 0 bytes after a block of size 20 alloc'd
==12345== at 0x4838B40: malloc
==12345== by 0x40058E: main (prog.c:5)

La prima riga indica il tipo e la dimensione dell'errore: 'Invalid write of size 4'.

La dimensione 4 indica un accesso di 4 byte, in genere un int. Questa singola riga indica la categoria di bug da aspettarsi prima di leggere il resto.

La riga at è il frame più interno, ovvero il punto in cui si è verificato l'errore. Ogni riga by indica il chiamante, un livello più in alto.

Legga dall'alto verso il basso, dal frame più profondo a quello più superficiale. Il primo frame con il nome del suo file è quasi sempre il punto del bug.

La riga Address ... individua l'accesso rispetto a un blocco noto:

• 0 bytes after a block of size 20 alloc'd — overflow appena oltre la fine
• 4 bytes inside a block of size 4 free'd — accesso dopo la liberazione
• on thread 1's stack — accesso allo stack

Mostra anche dove il blocco è stato allocato o liberato.

All'uscita viene fornito il riepilogo delle allocazioni:

==12345== HEAP SUMMARY:
==12345== in use at exit: 20 bytes in 1 blocks
==12345== total heap usage: 3 allocs, 2 frees, 1,044 bytes allocated

Un valore 'in use at exit' maggiore di zero indica che qualcosa non è stato liberato.

Sotto il riepilogo dell'heap, le perdite di memoria sono raggruppate:

definitely lost: 20 bytes in 1 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 0 bytes in 0 blocks

Aggiunga --leak-check=full per associare uno stack trace a ogni blocco perso.

L'ultima riga conta ogni elemento:

ERROR SUMMARY: 2 errors from 2 contexts

Un 'context' è una posizione di errore univoca. Se una riga difettosa viene eseguita un milione di volte in un ciclo, rimane comunque un solo context. L'obiettivo è 0 errors from 0 contexts.

Esamini il report con metodo:

• Corregga prima gli errori di accesso non valido, perché causano corruzione
• Passi poi agli errori relativi ai valori non inizializzati
• Infine corregga le perdite definitely e indirectly lost
• Esegua nuovamente il programma dopo ogni correzione; una causa principale spesso elimina diversi report

Alcuni errori provengono da librerie che non può correggere, come il runtime C o un driver grafico. Generi un file di soppressione per nasconderli senza occultare i bug del proprio codice.

--gen-suppressions=all stampa voci di soppressione pronte all'uso, che può salvare e passare nuovamente con --suppressions=file.

Interpreti una riga di un report.

Ora sa leggere i report di Valgrind dall'inizio alla fine:

• Il prefisso ==PID== identifica le righe di Valgrind, separandole dall'output del programma
• Ogni blocco di errore indica tipo, dimensione, stack trace e nota sull'indirizzo
• I riepiloghi HEAP/LEAK tengono conto delle allocazioni e della memoria persa
• ERROR SUMMARY conta i context univoci; punti a zero

Analizzi prima gli errori di accesso, poi le perdite di memoria, eseguendo nuovamente il programma man mano.