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

Geodrinx geodrinx a gmail.com
Mar 26 Maggio 2015 07:25:19 CEST


Alessandro,

ho provato a "testare" QGIS ma DrMemory mi dice che non funziona sui 64 bit.  :(

Tu sai se c'é un installer di DrMemory 64 per Windows ?

Ciao e grazie

Roberto

Inviato da iPhone

Il giorno 25/mag/2015, alle ore 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


Maggiori informazioni sulla lista Gfoss