Problematiche generali nella sezione valgrind

[Koldar]

1. sturmenti scritto male;
2. Valgrind è un framework di sturmenti. framework mi pare una parola troppa grossa. Collezione di strumenti od insieme di strumenti mi sembra più adeguato (a meno che loro stessi no nsi definiscano framework);
3. Attualmente (2017) Valgrind include sei validi strumenti: entrambe le liste proposte sono scritte totalmente in inglese. serve una traduzione (delle frasi, non dei termini tecnici) in italiano;
4. Per il mantra di valgrind, esso è valido solo per il comando "memcheck" (che poi è anche il principale). Gli altri non li ho completamente provati e quindi non posso assicurare che il mantra sia vero. Per il memcheck invece è più che consolidato! :)
5. Sezione "OUtputcon Valgrind": ci sono alcuni numeri molto importanti di cui non ha citato il significato. 1,024 bytes sono i byts usati in totale dal tuo programma: utilissimo per capire, a spanne, quanto il tuo programma consuma in termini di spazio. La frase "All heap blocks were freed -- no leaks are possible " identifica che il tuo programma non ha incoerenze di memoria e che tutto va bene. Ottenere quella frase con "memcheck" è l'obiettivo :). Nahc eil numero di allocs e di frees ha un suo peso (anche se minoritario): solitamente questo numero deve essere uguale.
6. Quando inizi subito a fare l'esempio di "unitialised variable" ti sei dimentica un fatto importante: quando compili e vuoi usare valgrind è necessario attivare la modalità di debug (-g): Essa ti permette di ottenere stack trace leggibili per le persone. Altrimenti quello che ottieni sono chiamate a funzione in numeri esadecimali non meglio comprensibili. INoltre è necessario specificare che valgrind non va d'accordo con le ottimizzazioni del codice, quindi è meglio evitare di compilare con "-OX" mentre si debugga con valgrind;
7. "Memcheck agisce solamente quando tenta di utilizzare un dato non inizializzato il cui utilizzo ha ripercussioni sul comportamento del programma": usare un dato non inizializzato notifica SEMPRE valgrind, non solo quando ha ripercussioni sul comportamento del programma.
8. "e di conseguenza lo è b" meglio "e di conseguenza non lo è neanche b". E poi cosa è "a"? nel codice sorgente non sembra esserci alcuna variabile "a";
9. "Memcheck osserva che il valore passato a _IO_printf e quindi a _IO_vfrprintf ma non solleva alcuna osservazione. Di fatti, Memcheck interviene solamente quando in _IO_Vfprintf si debba esaminare b per convertire il suo valore nel corrispondente ASCII, sollevando una osservazione": lo stack trace generato è quello completo. quindi valgrind ti fa vedere il punto in cui è stato usato un valore non inizializzato. Da quel che si vede la printf dentro il suo codice sorgente richiama altra variabile. Tuttavia non è quella la parte che ci interessa dello stack trace: infatti possiamo supporre che la funzione printf non abbia dentro di sé memory leak. Dovremmo quindi ripercorrere lo stack fino ad arrivare al codice che abbiamo scritto noi ("by 0x40055C: t_1 (in /root/a_01.out)" ma se metti la flag "-g" è più leggibile) e capire che la variabile non usata è in quella particolare linea.
10. "Prova a lanciare valgrind gcc file.c e confronta l'output con valgrind ./file.o (prima devi lanciare gcc file.c -o file.o). Cosa cambia?" mai chiamare file eseguibili con l'estensione ".o". La ".o" è riservata a file che contengono codice oggetto, non codice eseguibile. Altra cosa: valgrind va richiamato quando esegui il programma, non quando lo compili.
11. "indica la natura del problema: la libreria itoa.c": da punto 8. è chiaro che la libreria itoa è quella che genera il problema. Ma questo è dato perché noi abbiamo dato dei valori non congrui alla libreria stessa. Tramite lo stack trace, possiamo andare a vedere la linea in cui noi abbiamo dato a itoa valori sballati;

[Koldar]

12. "Valgrind non riesce a definire l'istruzione in esame, specie per il contesto in cui opera. Di fatto, Valgrind suggerisce due possibili cause": questo è un modo comodo di valgrind per dire: "potrei aver sbagliato, ma non credo proprio". Nella mia esperienza, questo è SEMPRE dovuto al programmatore. Dello stack smashing c'è da dire che per identificarlo correttamente devi compilare con una flag di compilazione chiamata -fno-stack-protector: alcuni compilatori proteggono strabordi di stack, ma così facendo non riesci a debuggare. E' chiaro che in ambienti di produzione essa vada riattivata (chiaramente) (https://stackoverflow.com/a/1347464/1887602);
13. Un altra cosa importante: Il tuo programma funziona bene anche quando c'è la scritta "definitely lost: 0 bytes in 0 blocks" (non hai memory leak).
14. "Sovvrascrivere " al posto "Sovrascrivere";

[RedsAnDev]

Done!

[RedsAnDev]

Done