fuite de mémoire

Bonjour,
j'ai réalisé une DLL en C++, en utilisant la librairie ADO, la DLL semble fonctionner mais apparemment, j'ai une fuite mémoire et je ne vois pas du tout d'où cela peut provenir.

Merci pour votre aide.

Voici une des fonctions de la DLL qui semble avoir des fuites de mémoire:

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 25 26 27 28 29 30

extern "C"__declspec(dllexport) void Deconnection(CString chemin, CString* etat) {   //déclarations des variables ADOConnect Conn; ADOError erreur; CString insertion;     //Connexion avec contrôle d'erreur if (!Conn.Connect(chemin)) { *etat = "erreur"; } else { *etat = "deconnecte"; } //écriture de la connexion ADOCommand Cmd2(Conn.ADOConn,"update CONNEXION set ETAT='Déconnecté' where NOM='toto'"); Cmd2.Execute();   //écriture dans le journal de bord insertion.Format("insert into journal_de_bord(type,nom) values('Déconnecté','toto')"); ADOCommand Cmd(Conn.ADOConn,insertion); Cmd.Execute();   //Deconnexion Conn.Disconnect(); }

---

La première chose à faire quand on a une fuite mémoire, c'est de vérifier chaque "new" du programme. 99% du temps, le problème vient de "new" sur des objets qui ne sont pas "deletés" après.

j'ai déjà corrigé les 'new' que j'avais oublié de deleter, mais là dans la prgrammation je ne vois pas ce qui peut géner.
(question bête: quand on fait un * (pointeur) on n'alloue pas de la mémoire qu'il faut libérer?)

A priori, les pointeurs sur tes chaînes sont désaloués automatiquement, t'as pas à t'en occuper.

Par contre, il arrive parfois que certains objets plus complexes ne puissent être automatiquement désaloués....moi je vérifierais les ADOCommand à ta place...mais bon, j'ai aucune certitude là-dessus.

Il y a 2 façon d'allouer de la mémoire:
1/ un new, par exemple:

Code:

---

1 2	MaClasse* c = new MaClasse();

---

dans ce cas, il faut impérativement appeler le destructeur (delete).

2/ déclarer un objet, par exemple:

Code:

---

1 2	MaClasse c;

---

dans ce cas, pas besoin d'appeler le destructeur puisqu'il s'agit d'une variable locale, qui sera automatiquement effacée à la sortie du bloc.

En revanche, quand tu fais:

Code:

---

*etat = "erreur";

---

Je ne sais pas ce quel est le type de la variable etat, donc je ne comprends pas trop ce que signifie cette ligne.

en fait 'etat' est le paramètre de retour (type pointeur) que renvoie la DLL au programme pricipal. c'est un CString.

Citation:

---

Envoyé par mamag

en fait 'etat' est le paramètre de retour (type pointeur) que renvoie la DLL au programme pricipal. c'est un CString.

---

:oops: j'avais pas vu, désolé :oops:
Quoi qu'il en soit, comme l'a dit pataguillon, le problème ne viens pas de

Code:

---

*etat = "erreur";

---

car ici, etat utilise un opérateur de recopie et "erreur" est considéré comme variable locale.

Donc je ne sais pas, désolé.

Comment sais-tu que tu as des fuites ? Si c'est un outil qui te le dit, il doit sûrement pouvoir te donner d'autres infos plus précises non ?

en fait, j'ai fournie la DLL à un client, c'est en l'utilisant qu'il s'est aperçu de fuite mémoire. c'est donc lui qui me l'a signalé. il m'a donné une trace sur la focntion , je n'arrive pas à la déchiffrer mais il y a marqué: detected memory leaks.

je n'ai vraiment pas l'habitude de programmer en C++ et je ne sais pas comment détecter les fuite mémoire sous visual C++ et encore moins interprété les traces.

je viens de faire un test en mode debug, et je me suis apreçue que ca m'engendrait une exception dans le fichier comip.h
mais un fichier de windows que je ne peux pas modifier
comment faire?

merci pour votre aide!

Citation:

---

je n'ai vraiment pas l'habitude de programmer en C++ et je ne sais pas comment détecter les fuite mémoire sous visual C++ et encore moins interprété les traces

---

Il y a un outil intégré à VC++ pour détecter les fuites. Regarde dans la FAQ, ou sur ce forum si tu ne trouves rien.

Sinon, il y a aussi plein d'outils gratuits externes.

Citation:

---

je viens de faire un test en mode debug, et je me suis apreçue que ca m'engendrait une exception dans le fichier comip.h
mais un fichier de windows que je ne peux pas modifier
comment faire?

---

Remonte la pile d'appels jusqu'à tomber dans une fonction qui provient de ton code à toi, et regarde quelle ligne pose problème.

c'est à dire que je n'y comprends pas grd chose
j'ai beaucoup de "C:\WINNT\system32\.....dll', no matching symbolic information found."
qui apparraissent mais pas de ligne sur mon programme?

Citation:

---

Envoyé par mamag

c'est à dire que je n'y comprends pas grd chose
j'ai beaucoup de "C:\WINNT\system32\.....dll', no matching symbolic information found."
qui apparraissent mais pas de ligne sur mon programme?

---

Tu confond: ce que tu nous donnes là ce sont des messages générés par le compilo lors de la compilation.
Il faut (quand l'exception est levée) ouvrir la pile d'appel (menu:debugger/fenêtres/pile d'appel)

Citation:

---

Envoyé par r0d

Citation:

---

Envoyé par mamag

c'est à dire que je n'y comprends pas grd chose
j'ai beaucoup de "C:\WINNT\system32\.....dll', no matching symbolic information found."
qui apparraissent mais pas de ligne sur mon programme?

---

Tu confond: ce que tu nous donnes là ce sont des messages générés par le compilo lors de la compilation.

---

En fait pas vraiment. Ce sont bien des messages de la sortie de debugging, mais ceux-ci indiquent seulement que tu n'as pas les versions debug des dlls windows (ce qui est tout à fait normal). Pour la pile d'appels et compagnie, va effectivement voir du côté du menu correspondant, il y a tout ce qu'il faut.

désolée, tu va me prendre pour une naz, mais je n'ai pas dans le menu, debugger/fenêtre/pile d'appel et je ne trouve rien qui y ressemble...

erf, si tu utilises Visual 6, je ne sais plus où c'est :oops:

et oui, j'ai visual 6...
je vais chercher encore
merci qd même pour ton aide

Salut,
La pile d'appel est accessible via view->debug window->call stack (en anglais)