[Gfoss] parzialmente OT: Dr. Memory (tool per sviluppatori)

[Davide Petrucci]

grazie mille è molto utile
ciao

Il giorno 25 maggio 2015 11:55, <a.furieri a lqt.it> ha scritto:

> visto che e' un tool abbastanza nuovo e non ancora troppo noto
> credo di fare una cosa potenzialmente utile segnalandovi questo
> pacchetto decisamente molto utile.
>
> Dr. Memory http://www.drmemory.org/
>
> recensione ultra-quick
> ----------------------
> si tratta di un analizzatore dinamico di codice, ed e' piu' o meno
> equivalente all'assai piu' noto Valgrind: http://valgrind.org/
>
> la cosa *molto* interessante e' che Dr. Memory gira indifferentemente
> sia su Windows (32 bit) sia su Linux e persino sotto Mac OsX, mentre
> invece Valgrind gira esclusivamente su Linux.
> finalmente abbiamo un tool completo ed abbastanza sofisticato anche
> sulle piattaforme Windows.
>
> detta in due parole, si tratta di strumenti sw che eseguono un
> programma qualsiasi al proprio interno tenendo sotto costante
> monitoraggio tutte le operazioni che interessano la memoria
> dinamica di tipo heap, cioe' quella che in C si gestisce tramite
> malloc/free ed in C++ tramite new/delete.
> l'unico pre-requisito richiesto e' che il programma bersaglio
> va compilato in modo un po' speciale, in modo tale da conservare
> all'interno dell'eseguibile tutti i numeri di linea che consentono
> di risalire al punto esatto del sorgente che causa il problema.
>
> nel 99% dei casi i bugs veramente rognosi da identificare e
> risolvere (quelli che accadono in modo apparentamente capriccioso
> e magari difficile da riprodurre in modo deterministico) affondano
> le proprie radici profonde proprio in quest'area critica.
> ecco spiegato perche' un tool diagnostico di questo tipo e' un
> vero e proprio toccasana che consente di arrivare a distribuire
> codice molto robusto e stabile a prova di bomba.
>
> le condizioni pericolose da tenere sempre sotto stretto controllo
> rientrano nelle seguenti categorie:
>
> - memory leaks: il programma alloca blocchi di memoria dinamica
>   che poi si dimentica sbadatamente di liberare quando non servono
>   piu'. la conseguenza negativa e' in questo modo pian piano la
>   memoria si esaurisce, le performances peggiorano progressivamente
>   ed infine si puo' anche arrivare ad un bel crash per esaurimento
>   delle risorse.
>   e' una condizione decisamente pericolosa per tutte le app con
>   una GUI, ma e' ancor piu' nefasta per i processi server che
>   restano ininterrottamente in esecuzione anche per mesi e mesi.
>
> - buffer overflow: il programma alloca p.es. 1000 bytes, ma poi
>   all'atto pratico cerca di leggerne o scriverne un po' di piu'
>   (p.es. 1005) finendo cosi' per sfondare i limiti dell'allocazione.
>   la cosa finisce assai spesso con qualche bel fuoco di artificio :-)
>
> - memoria non inizializzata: il programma dimentica di assegnare
>   esplicitamente un valore iniziale opportuno ai blocchi di memoria
>   dinamica che alloca via via.
>   dopo di che il primo tentativo di utilizzare comunque quei dati
>   puo' facilmente causare effetti stravaganti e bizzarri.
>   di fatto questo e' il meccanismo tipico che sta alla base di piu'
>   o meno tutti i "bugs misteriosi", quelli che "accade solo una
>   volta su mille", "accade solo sul PC di Giorgio, su tutti gli
>   altri PC funziona sempre perfettamente" o magari "su Linux gira
>   sempre bene, invece su Windows spesso va in crash ma a volte
>   funziona normalmente, dipende da come gli gira".
>
> usare regolarmente tools come Valgrind o Dr. Memory semplifica
> notevolmente il compito di identificare e poi risolvere tutti
> i pasticci e pasticcetti di questa natura.
> ecco spiegato perche' questi strumenti dovrebbero sempre fare
> parte integrante dei normali strumenti di sviluppo e verifica
> della qualita' per qualsiasi progetto di sw libero "serio".
>
> venendo piu' nello specifico a Dr. Memory:
> * alla prova dei fatti funziona sorprendenemte bene
> * l'installazione e' facilissima, cosi' come e' molto facile
>   compilare il programma da sottoporre a monitoraggio: basta
>   leggersi poche righe chiaramente documentate e praticamente
>   parte tutto da solo in cinque minuti.
> * su Win supporta indifferentemente sia MinGW che MSVC
> * il progetto ha nobilissime ascendenze, visto che si basa su
>   DynamoRIO, un toolkit sviluppato inizialmente da HP in
>   stretta collaborazione con il prestigioso MIT
> * last but not least, e' tutto free sw rilasciato sotto LGPL;
>   e' decismanete interessante scoprire che per i primi anni
>   ha mosso i propri passi come prodotto proprietario, ma piu'
>   di recente e' diventato sw libero a tutti gli effetti.
>   Evviva il figliol prodigo :-D
>
> ciao Sandro
>
> _______________________________________________
> Gfoss a lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 750 iscritti al 18.3.2015
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20150525/d73beae2/attachment.html>