debug de fuites memoire

twxs

12/07/2005 à 09:26

3dsman wrote:

salut!
bonjour

je suis a la recherche d'un outil efficace et pas trop compliquer pour
detecter les fuites memoires dans mes softs.
quelqu'un en aurais il un bien a me conseiller?

en payant, il y a bound checker, en gratuit, il y a quelque chose sur
codeproject me semble-t-il, si je retrouve l'url dans la journée je
l'enverrai.

twxs

kanze

12/07/2005 à 10:32

sman wrote:

je suis a la recherche d'un outil efficace et pas trop
compliquer pour detecter les fuites memoires dans mes softs.
quelqu'un en aurais il un bien a me conseiller?

La référence, c'est Purify, mais c'est cher. C'est extrèment
efficace, et pas trop compliqué à l'utilisation, mais le faire
passer par la service achats peut s'avérer compliqué.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Arnaud Meurgues

12/07/2005 à 12:35

3dsman wrote:

je suis a la recherche d'un outil efficace et pas trop compliquer pour
detecter les fuites memoires dans mes softs.
quelqu'un en aurais il un bien a me conseiller?

Il m'est arrivé, lorsque je ne pouvais pas utiliser purify, de faire
moi-même des classes pouvant aider à détecter des fuites mémoire. C'est
bien moins efficace que purify et ça demande d'instrumenter le code.
Mais ça s'est avéré utile dans certains cas.

Grossièrement, je redéfinis les new et les delete (ça ne détectera pas
de fuite sur malloc, donc) et stocke dans une liste tous les blocs
alloués. Lors de la désallocation, je retire les blocs de la liste.
Bien sûr, il faut redéfinir l'allocateur de la liste pour qu'il
n'utilise pas new et delete.

En faisant des observateurs locaux de la mémoire, on peut avoir un bilan
des allocations/désallocations pour une partie limitée du code. Le
pattern RAII permet d'observer facilement la mémoire dans un scope donné.

C'est loin d'être aussi précis et efficace que purify (ça ne donne pas
les piles à l'allocation et désallocation, notamment), mais ça peut
dépanner.

Arnaud

Pierre Maurette

12/07/2005 à 12:52

salut!
je suis a la recherche d'un outil efficace et pas trop compliquer pour
detecter les fuites memoires dans mes softs.
quelqu'un en aurais il un bien a me conseiller?
merci
Je n'ai fait de C++ un peu velu que sous C++Builder. Plus exactement,

en vertu d'un sain partage des tâches, C++Builder fait le C++ et moi
les bugs, mais peu importe.
J'utilise CodeGuard, paraît que ce n'est pas top, mais ça me suffit et
j'en suis content. Ce n'est bien entendu pas une réponse universelle.

--
Pour répondre directement: enlever une lettre sur deux
wwaannaaddoooo -> wanadoo

Pierre Maurette

Stephane Wirtel

12/07/2005 à 13:44

Tout en allant sur google pour rechercher ces informations, j'ai les questions suivantes.

Il m'est arrivé, lorsque je ne pouvais pas utiliser purify, de faire
moi-même des classes pouvant aider à détecter des fuites mémoire. C'est
bien moins efficace que purify et ça demande d'instrumenter le code.
Mais ça s'est avéré utile dans certains cas.

Grossièrement, je redéfinis les new et les delete (ça ne détectera pas
de fuite sur malloc, donc) et stocke dans une liste tous les blocs
alloués. Lors de la désallocation, je retire les blocs de la liste.
Bien sûr, il faut redéfinir l'allocateur de la liste pour qu'il
n'utilise pas new et delete.
Aurais-tu une doc expliquant la manipulation ?

En faisant des observateurs locaux de la mémoire, on peut avoir un bilan
des allocations/désallocations pour une partie limitée du code. Le
pattern RAII permet d'observer facilement la mémoire dans un scope donné.
Je vais me renseigner sur le pattern RAII, qui ne me dit absolument rien, mais je vais tout de même me renseigner.

C'est loin d'être aussi précis et efficace que purify (ça ne donne pas
les piles à l'allocation et désallocation, notamment), mais ça peut
dépanner.
Stéphane

Fabien LE LEZ

12/07/2005 à 14:28

On Tue, 12 Jul 2005 13:44:33 +0200, Stephane Wirtel
:

Je vais me renseigner sur le pattern RAII

Tu devrais trouver pas mal d'explications ici :
<http://www.google.com/advanced_group_search?hl=fr>.

Stephane Wirtel

12/07/2005 à 15:08

On Tue, 12 Jul 2005 13:44:33 +0200, Stephane Wirtel
:

Je vais me renseigner sur le pattern RAII

Tu devrais trouver pas mal d'explications ici :
<http://www.google.com/advanced_group_search?hl=fr>.

vlà mon ami google ;-)

L'initiative avait déjà été prise pour me renseigner sur ce sujet.

Merci Fabien

kanze

12/07/2005 à 15:13

Arnaud Meurgues wrote:

3dsman wrote:

je suis a la recherche d'un outil efficace et pas trop
compliquer pour detecter les fuites memoires dans mes softs.
quelqu'un en aurais il un bien a me conseiller?

Il m'est arrivé, lorsque je ne pouvais pas utiliser purify, de
faire moi-même des classes pouvant aider à détecter des fuites
mémoire. C'est bien moins efficace que purify et ça demande
d'instrumenter le code. Mais ça s'est avéré utile dans
certains cas.

Grossièrement, je redéfinis les new et les delete (ça ne
détectera pas de fuite sur malloc, donc) et stocke dans une
liste tous les blocs alloués. Lors de la désallocation, je
retire les blocs de la liste. Bien sûr, il faut redéfinir
l'allocateur de la liste pour qu'il n'utilise pas new et
delete.

En faisant des observateurs locaux de la mémoire, on peut
avoir un bilan des allocations/désallocations pour une partie
limitée du code. Le pattern RAII permet d'observer facilement
la mémoire dans un scope donné.

Ça ressemble drôlement à ce que je fais moi-même.

C'est loin d'être aussi précis et efficace que purify (ça ne
donne pas les piles à l'allocation et désallocation,
notamment), mais ça peut dépanner.

En général, générer un stack walkback n'est pas trop difficile.
Mais la technique dépend étroitement de la machine, et
l'afficher autrement qu'en hexadécimal exigerait pas mal de code
aussi.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Arnaud Meurgues

12/07/2005 à 15:43

wrote:

Ça ressemble drôlement à ce que je fais moi-même.

Ça doit être oins bien fini. J'ai fait ça rapidement pour un problème
ponctuel.

En général, générer un stack walkback n'est pas trop difficile.
Mais la technique dépend étroitement de la machine, et
l'afficher autrement qu'en hexadécimal exigerait pas mal de code
aussi.

Ça, ça m'intéresse bigrement. J'avais regardé un moment comment faire,
mais je m'étais laissé décourager (je n'avais pas assez de temps non plus).
En plus, mon code était supposé fonctionner sur plusieurs plateforme (vu
les différence d'implémentation des list, ça n'a pas été sans mal,
d'ailleurs).

Arnaud

Arnaud Meurgues

12/07/2005 à 15:57

Stephane Wirtel wrote:

Aurais-tu une doc expliquant la manipulation ?

Non, je n'ai pas de doc. L'idée de base part de la redéfinition des
opérateurs new et delete :

void* operator new(size_t s) {
void* mem = Allocator::Malloc(s);
return mem;
}
void operator delete(void* m) {
Allocator::Free(m);
}
void* operator new[] (size_t s) {
void* mem = Allocator::Malloc(s);
return mem;
}
void operator delete[] (void* m) {
Allocator::Free(m);
}

L'allocateur, lui, alloue les blocs par malloc et le signale à tous les
visiteurs abonnés (qui dérivent de la classe abstraite
Allocator::MemoryMonitorVisitor) :

class Allocator {
public:
class MemoryMonitorVisitor {
public:
virtual ~MemoryMonitorVisitor() {}
virtual void allocate(void* addr, size_t size) = 0;
virtual void free(void* addr) = 0;
};

static void* Malloc(size_t s) { return GetAllocator()->malloc(s); }
static void Free(void* mem) { GetAllocator()->free(mem); }
static void AddVisitor(MemoryMonitorVisitor* v) {
GetAllocator()->addVisitor(v);}
static void RemoveVisitor(MemoryMonitorVisitor* v) {
GetAllocator()->removeVisitor(v);}

void addVisitor(MemoryMonitorVisitor*);
void removeVisitor(MemoryMonitorVisitor*);

protected:
Allocator();
~Allocator();

private:
virtual void* malloc(size_t);
virtual void free(void*);

static Allocator* GetAllocator();
static Allocator* allocator;

typedef
std::list<MemoryMonitorVisitor*,CLikeAllocator<MemoryMonitorVisitor*> >
visitorslist;
visitorslist visitors;
};

void*
Allocator::malloc(size_t s) {
void* mem = ::malloc(s);

if (mem==0) {
throw "ERROR: can't allocate memory";
} else {
// call visitors
visitorslist::iterator i;
visitorslist::iterator end = visitors.end();
for (i=visitors.begin(); i!=end; ++i) {
(*i)->allocate(mem,s);
}
}
return mem;
}

void
Allocator::free(void* mem) {
if (mem == 0) return; // do nothing when freeing 0

// call visitors
visitorslist::iterator i;
visitorslist::iterator end = visitors.end();
for (i=visitors.begin(); i!=end; ++i) {
(*i)->free(mem);
}
::free(mem);
}

Et on peut ajouter ou supprimer des visiteurs :
void
Allocator::addVisitor(MemoryMonitorVisitor* v) {
visitors.push_back(v);
}
void
Allocator::removeVisitor(MemoryMonitorVisitor* v) {
visitors.remove(v);
}

Les list que j'utilisent ne peuvent pas utiliser new et delete, sinon il
y aurait des cycles infini. J'utilise donc ce que j'ai appelé
CLikeAllocator comme allocateur qui utilise malloc et free au lieu de
new et delete.
Ce code là n'est pas très portable car les limitations des compilos dans
la compilation des templates les oblige à implémenter un peu
différemment leurs listes et l'utilisation des allocateurs.

Je vais me renseigner sur le pattern RAII, qui ne me dit absolument
rien, mais je vais tout de même me renseigner.

C'est tout simple : On crée une variable automatique sur la pile
UnTypeDeRAII variableAuto;
Son constructeur initialise quelque chose (alloue une ressource, par
exemple, c'est ce qui a donné son nom au pattern : Ressource Acquisition
Is Initialization). Dans mon cas, il crée et abonne un visiteur.

Lorsque la variable est supprimée, en sortie de scope, son destructeur
est automatiquement appelé et peut terminer le processus (libérer les
ressources). Dans mon cas, il peut désabonner le visiteur et afficher un
rapport des allocations, par exemple.

Arnaud

Stephane Wirtel wrote:

Aurais-tu une doc expliquant la manipulation ?

Non, je n'ai pas de doc. L'idée de base part de la redéfinition des
opérateurs new et delete :

void* operator new(size_t s) {
void* mem = Allocator::Malloc(s);
return mem;
}
void operator delete(void* m) {
Allocator::Free(m);
}
void* operator new[] (size_t s) {
void* mem = Allocator::Malloc(s);
return mem;
}
void operator delete[] (void* m) {
Allocator::Free(m);
}

L'allocateur, lui, alloue les blocs par malloc et le signale à tous les
visiteurs abonnés (qui dérivent de la classe abstraite
Allocator::MemoryMonitorVisitor) :

class Allocator {
public:
class MemoryMonitorVisitor {
public:
virtual ~MemoryMonitorVisitor() {}
virtual void allocate(void* addr, size_t size) = 0;
virtual void free(void* addr) = 0;
};

static void* Malloc(size_t s) { return GetAllocator()->malloc(s); }
static void Free(void* mem) { GetAllocator()->free(mem); }
static void AddVisitor(MemoryMonitorVisitor* v) {
GetAllocator()->addVisitor(v);}
static void RemoveVisitor(MemoryMonitorVisitor* v) {
GetAllocator()->removeVisitor(v);}

void addVisitor(MemoryMonitorVisitor*);
void removeVisitor(MemoryMonitorVisitor*);

protected:
Allocator();
~Allocator();

private:
virtual void* malloc(size_t);
virtual void free(void*);

static Allocator* GetAllocator();
static Allocator* allocator;

typedef
std::list<MemoryMonitorVisitor*,CLikeAllocator<MemoryMonitorVisitor*> >
visitorslist;
visitorslist visitors;
};

void*
Allocator::malloc(size_t s) {
void* mem = ::malloc(s);

if (mem==0) {
throw "ERROR: can't allocate memory";
} else {
// call visitors
visitorslist::iterator i;
visitorslist::iterator end = visitors.end();
for (i=visitors.begin(); i!=end; ++i) {
(*i)->allocate(mem,s);
}
}
return mem;
}

void
Allocator::free(void* mem) {
if (mem == 0) return; // do nothing when freeing 0

// call visitors
visitorslist::iterator i;
visitorslist::iterator end = visitors.end();
for (i=visitors.begin(); i!=end; ++i) {
(*i)->free(mem);
}
::free(mem);
}

Et on peut ajouter ou supprimer des visiteurs :
void
Allocator::addVisitor(MemoryMonitorVisitor* v) {
visitors.push_back(v);
}
void
Allocator::removeVisitor(MemoryMonitorVisitor* v) {
visitors.remove(v);
}

Les list que j'utilisent ne peuvent pas utiliser new et delete, sinon il
y aurait des cycles infini. J'utilise donc ce que j'ai appelé
CLikeAllocator comme allocateur qui utilise malloc et free au lieu de
new et delete.
Ce code là n'est pas très portable car les limitations des compilos dans
la compilation des templates les oblige à implémenter un peu
différemment leurs listes et l'utilisation des allocateurs.

Je vais me renseigner sur le pattern RAII, qui ne me dit absolument
rien, mais je vais tout de même me renseigner.

C'est tout simple : On crée une variable automatique sur la pile
UnTypeDeRAII variableAuto;
Son constructeur initialise quelque chose (alloue une ressource, par
exemple, c'est ce qui a donné son nom au pattern : Ressource Acquisition
Is Initialization). Dans mon cas, il crée et abonne un visiteur.

Lorsque la variable est supprimée, en sortie de scope, son destructeur
est automatiquement appelé et peut terminer le processus (libérer les
ressources). Dans mon cas, il peut désabonner le visiteur et afficher un
rapport des allocations, par exemple.

Arnaud

Vous avez filtré cet utilisateur ! Consultez son message

Stephane Wirtel wrote:

Aurais-tu une doc expliquant la manipulation ?

Non, je n'ai pas de doc. L'idée de base part de la redéfinition des
opérateurs new et delete :

void* operator new(size_t s) {
void* mem = Allocator::Malloc(s);
return mem;
}
void operator delete(void* m) {
Allocator::Free(m);
}
void* operator new[] (size_t s) {
void* mem = Allocator::Malloc(s);
return mem;
}
void operator delete[] (void* m) {
Allocator::Free(m);
}

L'allocateur, lui, alloue les blocs par malloc et le signale à tous les
visiteurs abonnés (qui dérivent de la classe abstraite
Allocator::MemoryMonitorVisitor) :

class Allocator {
public:
class MemoryMonitorVisitor {
public:
virtual ~MemoryMonitorVisitor() {}
virtual void allocate(void* addr, size_t size) = 0;
virtual void free(void* addr) = 0;
};

static void* Malloc(size_t s) { return GetAllocator()->malloc(s); }
static void Free(void* mem) { GetAllocator()->free(mem); }
static void AddVisitor(MemoryMonitorVisitor* v) {
GetAllocator()->addVisitor(v);}
static void RemoveVisitor(MemoryMonitorVisitor* v) {
GetAllocator()->removeVisitor(v);}

void addVisitor(MemoryMonitorVisitor*);
void removeVisitor(MemoryMonitorVisitor*);

protected:
Allocator();
~Allocator();

private:
virtual void* malloc(size_t);
virtual void free(void*);

static Allocator* GetAllocator();
static Allocator* allocator;

typedef
std::list<MemoryMonitorVisitor*,CLikeAllocator<MemoryMonitorVisitor*> >
visitorslist;
visitorslist visitors;
};

void*
Allocator::malloc(size_t s) {
void* mem = ::malloc(s);

if (mem==0) {
throw "ERROR: can't allocate memory";
} else {
// call visitors
visitorslist::iterator i;
visitorslist::iterator end = visitors.end();
for (i=visitors.begin(); i!=end; ++i) {
(*i)->allocate(mem,s);
}
}
return mem;
}

void
Allocator::free(void* mem) {
if (mem == 0) return; // do nothing when freeing 0

// call visitors
visitorslist::iterator i;
visitorslist::iterator end = visitors.end();
for (i=visitors.begin(); i!=end; ++i) {
(*i)->free(mem);
}
::free(mem);
}

Et on peut ajouter ou supprimer des visiteurs :
void
Allocator::addVisitor(MemoryMonitorVisitor* v) {
visitors.push_back(v);
}
void
Allocator::removeVisitor(MemoryMonitorVisitor* v) {
visitors.remove(v);
}

Les list que j'utilisent ne peuvent pas utiliser new et delete, sinon il
y aurait des cycles infini. J'utilise donc ce que j'ai appelé
CLikeAllocator comme allocateur qui utilise malloc et free au lieu de
new et delete.
Ce code là n'est pas très portable car les limitations des compilos dans
la compilation des templates les oblige à implémenter un peu
différemment leurs listes et l'utilisation des allocateurs.

Je vais me renseigner sur le pattern RAII, qui ne me dit absolument
rien, mais je vais tout de même me renseigner.

C'est tout simple : On crée une variable automatique sur la pile
UnTypeDeRAII variableAuto;
Son constructeur initialise quelque chose (alloue une ressource, par
exemple, c'est ce qui a donné son nom au pattern : Ressource Acquisition
Is Initialization). Dans mon cas, il crée et abonne un visiteur.

Lorsque la variable est supprimée, en sortie de scope, son destructeur
est automatiquement appelé et peut terminer le processus (libérer les
ressources). Dans mon cas, il peut désabonner le visiteur et afficher un
rapport des allocations, par exemple.

Arnaud

debug de fuites memoire

10 réponses

Veuillez sélectionner un problème