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