Cherche Plombier pour bonne fuite Mémoire!

Version imprimable

31/05/2008, 18h48
TNT89

1 pièce(s) jointe(s)

Cherche Plombier pour bonne fuite Mémoire!

Bonjour,

Je travaille actuellement sur un petit projet scolaire en C++ mais je rencontre des problèmes sur celui-ci qui ne sont pas d'ordre syntaxique. Je pense donc que le code produit une fuite mémoire mais je n'arrive pas à la localiser.

Je travaille actuellement sur Code::Blocks 8.02 et avec GCC (tout est correctement installé et tourne parfaitement sur d'autre projets). Ci-joint le code et le projet au format CBP. En fait, si une âme charitable voulait bien relire ce code s'il vous plait car je suis vraiment à court d'idée...

But du programme
Recherche de pattern oscillant dans les automates cellulaires (pour l'instant : B3S23 le jeu de la vie) selon un algorithme 'Brut Force'. Les tables sont compressé en 1 booléen pour 1 bit (système de masque binaire etc...).

Symptômes
Fichiers log.cpp et log.hpp : j'ai essayé de refaire un log façon
C++ histoire de... Malheureusement la spécialisation de l'opérateur ++ lève une erreur du linker "Multiple definition of..." je pense que l'inclusion des headers peut être en cause bien qu'ils soient protégés, enfin je crois...
Fichiers Table.hpp et Table.cpp : normalement ici tout fonctionne, à vérifier quand même...
Fichiers Handler.hpp et Handler.cpp : ici c'est toute la gestion du programme. La cause des problèmes est peut être l'allocateur de Table bien qu'il me semble être correct...

A la compilation : aucune erreur.
En utilisant le debugger : le programme se finit normalement, aucun segfault/sigsev.
Au cours du programme : des adresses NULL confondues avec des adresses
correcte (en utilisant ==) : cf le fichier généré log.txt.

Je vous remercie d'avance...
31/05/2008, 22h25
TNT89

Début de correction des bugs : il sembleraient que l'inclusion de "./MainHeader.h" à partir de n'importe quel fichier cpp génère les "Multiple definition of..." mais je ne sais pas pourquoi...
Si quelqu'un a une idée...
01/06/2008, 03h37
bolhrak

Hello,

Pour ton problème de fuite mémoire tu devrais essayer de brancher le gestionnaire mémoire du tutoriel de conception d'un moteur 3D de Laurent Gomilla, ça devrait te donner un point de départ sur les ressources non libérées.

edit : j'avais pas fait attention que ta classe Log n'est pas template, donc ma première remarque ne tient plus, je l'ai supprimée.

Salut,

Pour commencer, je vais me permettre quelques remarques au sujet de ta class log...

Un petit rappel, d'abord: les définitions des fonctions template doivent se trouver dans les fichiers d'en-tête.

Ensuite, il semblerait de bon ton d'éviter la copie des objets que tu passe à l'opérateur << de ta classe log...

L'idéal étant de fournir une référence constante vers ces différents objet.

Ainsi, le constructeur serait bien plus à son aise sous la forme de

Code:

LoG(const std::string& filename)

et ta surcharge de operator<< le serait également sous la forme de
Code:

1 2 template<typename TYPE> LoG& operator<<(const TYPE& obj);
Ainsi, la seule spécialisation partielle sous la forme de
Code:

1 2 3 4 5 6 template<> Log& Log::operator<< <std::string>(const std::string& obj) { log_list.back() += obj; return (*this); }
suffirait-elle (grace au constructeur de la classe std::string qui prend un ... const char*) à travailler aussi bien avec une std::string qu'avec ... un const char* ;)

Pour les autres spécialisations partielle, bien qu'il n'y ait que peu d'avantages à travailler sur des références constantes vers des types primitifs, cela ne fait pas de tort pour autant, donc... autant en profiter ;)

Ensuite (au fait, pour permettre la compilation de handler.cpp, il faut inclure le fichier d'en-tête <cstring> pour disposer de memcpy ;)).

Ainsi, la définition de la méthode void TABLE::reclip_me(void), m'incite à plusieurs remarques:
i et j sont des compteurs de boucle... l'idée générale étant de déclarer les variables quand on en a besoin, leur déclaration pourrait très bien se faire directement dans la boucle sous les boucles sous la forme de
Code:

1 2 3 4 for(int j=0; j<h; j++) { for(int i=0; i<w; i++) {
De plus, et je ne fais ici qu'émettre un avis personnel (que beaucoup partagent d'ailleurs), si le langage accepte les listes de déclarations de variables de même type en les séparant par des virgules, l'idée générale est que le code est bien plus souvent lu qu'il n'est écrit, et que, bien que cela permette de gagner quelques (dixièmes de) secondes lors de l'écriture du code à utiliser cette possibilité, il est préférable de malgré tout veiller à ne faire qu'une déclaration de variable par ligne.

Tu peux de toutes manières faire confiance au compilateur pour optimiser un code qui prendrait la forme de
Code:

1 2 3 4 int Xmin; int Xmax; int Ymin; int Ymax;
mais tu évite le risque qu'un lecteur un peu distrait ne remarque pas tout de suite qu'il s'agit de... 4 déclarations ;)

En outre, il faudrait que tu sois attentif à gérer les différents avertissement lancés par le compilateur quand il est bien réglé:

Les avertissements ne sont pas tes ennemis, bien au contraire...

Ils t'indiquent que tu prend un risque, malgré le fait que ton code est syntaxiquement correct.

En réglant ton compilateur sur un mode "paranoïaque", tu obtiendrait les avertissements suivants concernant cette méthode:
Code:

1 2 3 4 5 D:\projects\LifeFinder\Source\Tables.cpp||In member function 'void TABLE::reclip_me()':| D:\projects\LifeFinder\Source\Tables.cpp|189|attention : 'Ymin' may be used uninitialized in this function| D:\projects\LifeFinder\Source\Tables.cpp|188|attention : 'Xmax' may be used uninitialized in this function| D:\projects\LifeFinder\Source\Tables.cpp|188|attention : 'Xmin' may be used uninitialized in this function| D:\projects\LifeFinder\Source\Tables.cpp|189|attention : 'Ymax' may be used uninitialized in this function|
qui t'indiquent, tout simplement, que tes différentes variables risque d'être utilisées sans que tu ne les aie initialisées de manière correcte, avec tous les risques que cela peut comporter.

Comme la solution est relativement simple, autant "blinder" le code de ce coté là: il suffit, pour les *min, de fournir une valeur plus petite que la valeur minimale que tu dois gérer (ici, sans doute plus petite que 0) et pour les *max, une valeur plus grande que celle que tu dois gérer (par exemple MAX_INT)

Cela pourrait prendre chez toi, étant donné que tu dispose des valeurs v et w, une forme proche de
Code:

1 2 3 4 int Xmin=-1; int Ymin=-1; int Xmax=w+1; int YMax=h+1;
Cela aura pour résultat immédiat de t'éviter d'avoir, en plus, à gérer le fait que ce soit ou non le premier passage dans la boucle, et donc de t'éviter le test if(begin), étant donné que tu serait sur que les valeurs correspondantes au début sont de nature à forcer la modification ;) :D

De la même manière, si la fonction main() prend des arguments, le premier doit être un int...

Le prototype de main est donc soit
Code:

1 2 3 4 int main() { } soi
t
Code:

1 2 3 int main(int argc, char* argv[]) { }
Enfin, il faut se méfier de la fonction system, qui n'est absolument pas portable...

A vrai dire, c'est surtout du au fait que tu n'est absolument pas sur que la commande que tu invoques existe sur les différents système d'exploitation possibles... Et la cas de "pause" est symptomatique: la commande n'existe que sous windows.

C'est pourquoi, je te conseillerais volontiers de remplacer cette commande honnie s'il en est par l'alternative proposée dans la FAQ

Bien sur, tout ceci ne fait pas avancer ton problème... Mais, comme ces remarques générales sont de nature à te permettre d'améliorer ta manière de programmer et que mon message devient déjà fort long, je vais te laisser méditer dessus, et essayer de trouver un peu de temps pour observer ton code de manière plus détaillée ;)

01/06/2008, 10h09
TNT89

Merci de vos réponses,

Pour la classe LOG, j'évoque mon problème sur ce message. J'avais commencer en utilisant les références mais les avait supprimées car les spécialisation de char et const char* reçoivent plus souvent des données directes que des variables...

Citation:

Ensuite (au fait, pour permettre la compilation de handler.cpp, il faut inclure le fichier d'en-tête <cstring> pour disposer de memcpy ).

Je suis étonné que le code compile parfaitement sans cette inclusion...peut-être est-il déjà inclut dans le réseau d'en-tête du programme???

Citation:

En réglant ton compilateur sur un mode "paranoïaque", tu obtiendrait les avertissements suivants concernant cette méthode:

Je les obtiens mais ils n'ont pas de valeur...Par contre je ne vois pas comment je puis supprimer le cas de départ (avec le booléen begin). Cette fonction à pour but de trouver le plus petit rectangle contenant le motif (+1 ligne et +1 colonne de marge de chaque côté...)...Si je lui spécifie la région entière, la fonction sera incapable de trouver cette zone...Donc pour le moment j'initialise à 0 mais je laisse le cas de départ...

Pour main et reprenant l'expression d'un autre posteur du forum, j'ai eu une longue période d'infidélité...:(

Enfin pour system, je l'enlève, je n'en ai pas forcément besoin...

Citation:

Envoyé par TNT89

Merci de vos réponses,

Pour la classe LOG, j'évoque mon problème sur ce message. J'avais commencer en utilisant les références mais les avait supprimées car les spécialisation de char et const char* reçoivent plus souvent des données directes que des variables...

Sauf que, à bien y réfléchir, un const char et un const char* se marient très bien avec une const std::string& ;) :P

Citation:

Je suis étonné que le code compile parfaitement sans cette inclusion...peut-être est-il déjà inclut dans le réseau d'en-tête du programme???

J'ai pourtant utilisé ton fichier de projet code::blocks, et il m'a gentiment jeté à la compilation sous prétexte que memcpy n'était pas déclaré (j'ai du rajouter <cstring> pour que ca fonctionne ;))

Citation:

Je les obtiens mais ils n'ont pas de valeur...

Si, ils ont une valeur: ils te signalent qu'une variable risque de ne pas être initialisée lorsque tu voudra l'utiliser, car les différentes valeurs se présentent dans une partie de test qui peut ne jamais être effectuée, et ce, même si tu force le passage dans cette partie du test...

Ce qui démontre, justement, le problème d'algorithme que je m'apprête à te attaquer ;)

Citation:

Par contre je ne vois pas comment je puis supprimer le cas de départ (avec le booléen begin). Cette fonction à pour but de trouver le plus petit rectangle contenant le motif (+1 ligne et +1 colonne de marge de chaque côté...)...Si je lui spécifie la région entière, la fonction sera incapable de trouver cette zone...Donc pour le moment j'initialise à 0 mais je laisse le cas de départ...

Hé bien, voyons un peu le raisonnement que tu suit:

Tu déclares tes variables, et, parmi elles, tu défini begin à vrai.
tu rentre dans tes boucles imbriquées et tu effectue ton test pour savoir si elle est vivante (au passage, l'écriture du test sous la forme de if( get(i, j)==true) serait peut etre plus lisible... j'aime bien les codes où les choses sont clairement explicites :D)
Si elle est vivante, tu teste si begin est toujours à vrai, et si oui:

tu fournit les valeurs à Xmin, Xmax, Ymin et Ymax
tu assigne enfin la valeur false à begin.
sinon

tu vérifie si i est plus petit que Xmin (tu assigne i à Xmin si c'est le cas)
tu vérifie si i est plus grand que Xmax (tu assigne i à Xmax si c'est le cas)
tu vérifie si j est plus petit que Ymin (tu assigne j à Ymin si c'est le cas)
tu vérifie si j est plus grand que Ymax(tu assigne j àYmax si c'est le cas)
tu termine ta gestion

Moi, ce que je te propose, c'est tout simple: initialise d'office tes variables à des valeurs dont tu sais pertinement bien qu'elles devront être modifiées...

C'est à dire - me culpa, j'ai inversé les valeurs à fournir - que tu dois donner une valeur à tes minima plus grande que la plus grande des valeurs que tu risque de rencontrer et à tes maxima, une valeur plus petite que la plus petite des valeurs que tu peux rencontrer...

Ainsi, tu es sur que tes variables seront d'office correctement initialisées

Comme, de toutes manière, les valeurs correspondant à Xmin et Xmax seront évaluées entre 0 et w et que les valeurs correspondant Ymin et Ymax seront évaluées entre 0 et h, il te suffit d'initialiser Xmin à plus que w, Xmax à moins que 0, Ymin à plus que h et Ymax à moins que 0...

Ainsi, le code peut devenir
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 int Xmin = w+1; //+1, ca suffit pour etre "plus grand" que le plus grand ;) int Xmax = -1; //-1 suffit pour etre "plus petit" que 0 ;) int Ymin = h+1; //quoi, tu ne m'as pas compris la première fois ??? :D int Ymax = -1; //idem for(int j=0;j<h;++j) for(int i=0;i<w;++i) { if( get(i, j)==true ) //j'aime les code verbeux :D { /* meme la première fois que les boucles seront effectuées, nous * sommes sur de passer dans les quatre tests */ if(i<Xmin) Xmin = i; if(i>Xmax) Xmax = i; if(j<Ymin) Ymin = j; if(j>Ymax) Ymax = j; } } } /* suite de la méthode */
Le résultat est quadruple:

tu as moins de lignes de code, ce qui facilite la lecture
Le compilateur est content, car toutes tes variables sont correctement initialisées
tu supprime une variable devenue inutile
tu supprime un test devenu inutile, et tu gagne donc en performances à l'exécution (il s'agit ici d'une optimisation qui n'a rien de pré maturée ;))

Bref, tu gagne sur tous les tableaux ;) :D

01/06/2008, 12h19
TNT89

Oui, effectivement, je n'avais pas penser à croiser les valeurs :oops:.
Merci :D.

Par contre je ne comprends toujours pas pour le memcpy. CodeBlocks ne me jetais pas sur le programme que j'ai envoyé... :?

Pour le LOG j'ai toujours des "Multiple definitions" si j'essaye de compiler avec les templates...
01/06/2008, 13h12
koala01

Citation:

Envoyé par TNT89

Oui, effectivement, je n'avais pas penser à croiser les valeurs :oops:.
Merci :D.

Ah, ben, oui... mais ca, c'est ce qui fait toute la différence entre réfléchir un peu ou non :D
:dehors:

Citation:

Par contre je ne comprends toujours pas pour le memcpy. CodeBlocks ne me jetais pas sur le programme que j'ai envoyé... :?

C'est peut être propre à ma situation personnelle: je travaille avec gcc 4.3.0 ;)

Citation:

Pour le LOG j'ai toujours des "Multiple definitions" si j'essaye de compiler avec les templates...

Déclare ta fonction inline et défini tes spécialisations comme telles ;)
01/06/2008, 14h46
TNT89

Citation:

Ah, ben, oui... mais ca, c'est ce qui fait toute la différence entre réfléchir un peu ou non

ça fait surtout la différence pendant les DS (Devoirs Surveillés) d'algorithmique... :aie:

Petite question pourquoi je dois forcément passer les spécialisation en inline???
01/06/2008, 15h10
koala01

Citation:

Envoyé par TNT89

ça fait surtout la différence pendant les DS (Devoirs Surveillés) d'algorithmique... :aie:

Aussi... je n'osais pas trop aborder ce sujet :aie:

Citation:

Petite question pourquoi je dois forcément passer les spécialisation en inline???

Bien, disons, que, normalement, les fonctions template sont de toutes manière inlinée du fait qu'il est impossible de savoir sur quel objet elles vont s'appliquer avant ... de savoir le contexte dans lequel elles sont appelées.

Le fait de les déclarer explicitement inline permet donc simplement de rappeler au compilateur qu'il doit travailler correctement :D