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

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 :slight_smile:

- 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 :smiley:

ciao Sandro

+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 <a.furieri@lqt.it>:

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 :slight_smile:

- 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 :smiley:

ciao Sandro

_______________________________________________
Gfoss@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

grazie mille è molto utile
ciao

···

Il giorno 25 maggio 2015 11:55, <a.furieri@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 :slight_smile:

  • 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 :smiley:

ciao Sandro


Gfoss@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

Alessandro,

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

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@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 :slight_smile:

- 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 :smiley:

ciao Sandro

_______________________________________________
Gfoss@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

On Tue, 26 May 2015 07:25:19 +0200, Geodrinx wrote:

Alessandro,

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

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

lo dice chiaramente nelle istruzioni:
"Dr. Memory currently targets 32-bit applications only."

se non erro esiste anche una versione di QGIS a 32 bit (x86); usa
quella, gira sicuramente anche se il tuo PC usa una CPU x86_64

comunque il problema vero e' che se non usi una versione di
QGIS compilata in modo tale da conservare internamente tutti
i numeri di linea dei sorgenti (modalita' debug) otterrai
comunque una diagnostica praticamente incomprensibile e di
ben scarsa utilita'.
i settings da usare per compilare sia sotto MSVC che MinWG
li trovi chiaramente indicati qua:

http://drmemory.org/docs/page_prep.html

ciao Sandro

On Tue, May 26, 2015 at 08:15:42AM +0200, a.furieri@lqt.it wrote:

On Tue, 26 May 2015 07:25:19 +0200, Geodrinx wrote:
>Alessandro,
>
>ho provato a "testare" QGIS ma DrMemory mi dice che non funziona sui
>64 bit. :frowning:
>
>Tu sai se c'é un installer di DrMemory 64 per Windows ?

lo dice chiaramente nelle istruzioni:
"Dr. Memory currently targets 32-bit applications only."

Nemmeno ricompilandolo ? Strano !

--strk;

On Tue, 26 May 2015 10:13:28 +0200, Sandro Santilli wrote:

On Tue, May 26, 2015 at 08:15:42AM +0200, a.furieri@lqt.it wrote:

On Tue, 26 May 2015 07:25:19 +0200, Geodrinx wrote:
>Alessandro,
>
>ho provato a "testare" QGIS ma DrMemory mi dice che non funziona sui
>64 bit. :frowning:
>
>Tu sai se c'é un installer di DrMemory 64 per Windows ?

lo dice chiaramente nelle istruzioni:
"Dr. Memory currently targets 32-bit applications only."

Nemmeno ricompilandolo ? Strano !

Strk,

pensandoci su non e' poi cosi' tanto strano.

questi tools lavorano come se fossero una virtual machine:
intercettano il codice macchina e lo eseguono in modo indiretto
piu' o meno come se fosse un p-code (infatti introducone sempre
un rallentamento piu' o meno vistoso).
in questo modo riesconoo a tenere traccia di tutti gli indirizzamenti
e possono efficacemente verificare se accadono pasticci strani.

ma amd64 / x86_64 presenta delle grosse differenze rispetto al
vecchio x86 proprio per quanto riguarda l'architettura HW dei
registri di indirizzamento: in particolare supporta la modalita'
"Position Independent Code (PIC)" che non ha equivalenti su x86.
non a caso quando si compila una DLL per amd64 gcc pretende sempre
che venga specificata esplicitamente l'opzione -fPIC

non pare poi cosi' inverosimile che per implementare il supporto
anche per amd64 serva un po' di lavoro extra, che evidentemente
ancora nessuno ha fatto :stuck_out_tongue:

ciao Sandro