+1 Luigi Pirelli ************************************************************************************************** * LinkedIn: https://www.linkedin.com/in/luigipirelli * Elance: https://www.elance.com/s/edit/luigipirelli/ * GitHub: https://github.com/luipir * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli * Mastering QGIS: https://www.packtpub.com/application-development/mastering-qgis **************************************************************************************************
2015-05-25 11:55 GMT+02:00 <[email protected]>: > 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 > > _______________________________________________ > [email protected] > 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 _______________________________________________ [email protected] 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
