[MFC] Problème de mémoire jamais désallouée

**nmarf** · 26/01/2006, 16h31

Boujour à tous,

Voici mon problème :

Une appli en TCL lancée en tâche de fond écrit des fichiers tif à intervalle régulier. Une appli MFC constamment visible utilise un timer pour afficher les 20 dernières images écrites par le TCL. Un bouton dans cette appli permet dans lancer un autre dont le but est de visualiser toutes les images TIF générées dans une fenêtre scrollable. Voilà pour le contexte.

Mon appli a été testée seule (cad sans le TCL et l'autre appli en fond) et il n'y a pas de fuites mémoire (à priori, vérifications faites avec le TaskManager et l'exécution en mode Debug).
Mais maintenant que j'essaie de la lancer avec tout le monde, j'ai l'impression que les désallocation ne fonctionnent plus car la mémoire augmente à chaque nouveau chargement et pire, quand on quitte elle reste allouée

Comment être sûr que les désallocation se fassent ? J'ai essayé avec des CriticalSections mais sans succés (peut-être m'y suis-je mal pris...).

:

**farscape** · 26/01/2006, 17h02

c'est l'application MFC graphique qui ne libere pas la memoire?

**nmarf** · 26/01/2006, 17h25

Effectivement, ce n'est pas super clair...

Il semblerait que ce soit dans l'appli MFC qui affiche tous les défauts que se trouve le problème : quand je scroll, la mémoire totale utilisée augmente BIEN QUE la mémoire du process correspondant ne varie pas

**farscape** · 26/01/2006, 17h34

tu as regardé l'occupation GDI ? (c'est une colonne a rajouter dans le gestionnaire de taches).
sinon si c'est vraiment du memory leaks lance ton programme en trace debug .
quand tu fermes l'application tu devrais avoir les traces des alloc non relachés .
(a condition d'avoir les macros :#define new DEBUG_NEW etc..)

**nmarf** · 27/01/2006, 09h55

Envoyé par farscape

tu as regardé l'occupation GDI ? (c'est une colonne a rajouter dans le gestionnaire de taches).

Est-ce que tu parles de la colonne GDI Objects ? Si c'est le cas, impossible de l'afficher sur la machine où je fais les tests (NT allégé), même si on peut la cocher dans le menu Select Columns. Par contre, sur ma machine de travail (XP), pas de problèmes...

Envoyé par farscape

sinon si c'est vraiment du memory leaks lance ton programme en trace debug .
quand tu fermes l'application tu devrais avoir les traces des alloc non relachés .
(a condition d'avoir les macros :#define new DEBUG_NEW etc..)

Je ne sais pas si c'est le mode trace debug mais j'ai déjà lancé l'application en debug, poussé le programme dans ses retranchements (ouverture de plus de dialog possible, lecture d'un grand nombre d'images...) et consulté ce que me dit Visual dans la partie Debug : aucune ligne avec Memory leaks n'apparaît, je pense les avoir assez bien chassés

En tout cas, merci de te pencher sur mon problème.

**farscape** · 27/01/2006, 10h00

bien
si pas de problemes coté objets GDI ,pas de leaks detectés coté debug ,
c'est etrange..
alors eventuellement attention a l'eventuel melange de la lib CRT avec les differentes lib que peut utiliser ton programme .
on a evoqué ce probleme avec r0d il n'y a pas trop longtemps.

**r0d** · 27/01/2006, 10h10

Mmhh, ce n'était pas vraiment la même chose. Dans mon cas, c'était l'inverse, c'est à dire que j'obtenais des memory leaks à cause des différentes CRT alors qu'il n'y en avait pas.

En ce qui concerne les memory leaks, tu utilise bien la fonction _CrtCheckMemoryLeaks()?

**nmarf** · 27/01/2006, 15h08

Envoyé par r0d

En ce qui concerne les memory leaks, tu utilise bien la fonction _CrtCheckMemoryLeaks()?

Non, je lance juste en mode Debug et je consulte Visual après l'exécution.
Je n'ai rien trouvé à propos de _CrtCheckMemoryLeaks().
Sinon, je viens d'essayer _CrtCheckMemory() dans la fonction de fermeture de l'appli et elle ne me renvoie rien de particulier.

:

**farscape** · 27/01/2006, 15h21

moi ça m'inspire une chose :
Ou le constat est erroné ou les méthodes de diagnostics en debug sont shuntées.(macro citée plus haut absente )
Il faut reprendre depuis le début et établir un constat clair et quantifiable
Par le gestionnaire de tache et le debugger en mettant des points d'arrêts à des endroits stratégiques.
Exemple : avant de sortir du programme dans Exitinstance ou dans le destructeur de la classe d’application.
Que dit le gestionnaire des taches en occupation mémoire du process ?

**nmarf** · 30/01/2006, 09h35

Bonjour,

Je n'ai pas trouvé de fonction ExitInstance mais avec le destructeur de ma classe principale (qui n'existait pas, j'ai du le rajouter) et le gestionnaire des tâches, j'ai ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
                              Mem Usage   GDI Objects
1ère ligne du constructeur    5064k       29
fin de l'init de l'appli      6596k       59
après le chargement d'images  12036k      75
dans le destructeur           12036k      70

**farscape** · 30/01/2006, 09h38

il semble bien que tu as des fuites GDI non ?

**nmarf** · 30/01/2006, 09h49

A quoi vois-tu ça, et quelles peuvent en être les causes ?
(désolé mais j'ai tant à apprendre...)

**farscape** · 30/01/2006, 19h58

Envoyé par nmarf

A quoi vois-tu ça, et quelles peuvent en être les causes ?
(désolé mais j'ai tant à apprendre...)

et bien si je ne me trompe pas tu as 59 objets GDI ouvert quand ton application est initialisée en sortie tu as 70 objets..
apres le chargement d'images tu as 12036 K en memoire .
dans le destructeur toujours pareil ...
sauf si le gestionnaire de taches n'a pas pu mettre a jour ses infos c'est pas normal..
peut etre qu'un afxmessageBox dans le destructeur en release serait plus juste.
la cause ,objet gdi non relachés, DC sans releaseDC (suivant les cas) ,bitmap ,sans voir le code difficile de repondre .

**nmarf** · 31/01/2006, 10h56

J'ai trouvé un outil (ICI) qui permet de savoir le type et le nombre de GDI utilisés pour chaque process en cours. Il est même possible de voir le contenu de certains. J'ai relevé les valeurs à chaque étape en Release et voilà ce que ça donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
   Name            ID    #Handles  Bitmap  Brush  DC  Font  Palette  Pen  ExtPen  Region  Other
1. OfflineBrowser  5184  43 [41]   2       14     2   15    0        1    0       7       0
2. OfflineBrowser  5184  65 [61]   14      17     4   18    1        1    0       6       0
3. OfflineBrowser  5184  79 [75]   16      27     5   18    1        2    0       6       0
 
1. MessageBox à la 1ère ligne du constructeur
2. Début de l'appli
3. Lecture de beaucoup d'images

Les Bitmaps visibles dans l'outil sont les boutons utilisés (classe dérivée des KbcButtons trouvés ICI)

Par contre, j'ai eu beau mettre un MessageBox dans le destructeur de la classe d'application, il ne s'affiche pas. C'est étonnant car j'arrive à m'y arrêter en Debug avec un point d'arrêt.

**nmarf** · 31/01/2006, 11h15

En Debug, j'ai les mêmes valeurs. La différence est juste que je peux les récupérer au moment de la destruction, ce qui me donne ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Name            ID    #Handles  Bitmap  Brush  DC  Font  Palette  Pen  ExtPen  Region  Other
OfflineBrowser  7672  74 [70]   15      25     5   16    1        2    0       6       0

**findwin** · 31/01/2006, 11h26

après avoir utilisé un objet GDI, par exemple un CPen ou un CBrush, il faut le détruire avec sa méthode DeleteObject()...

Je ne sais pas si ça peut t'aider

**nmarf** · 31/01/2006, 14h00

Est-ce qu'il faut utiliser DeleteObject à chaque fois ? Il me semble avoir lu que les objets étaient détruits proprement dès qu'ils sont hors de portée. Dans quels cas alors n'est-ce pas le cas ?

**farscape** · 31/01/2006, 14h31

Envoyé par nmarf

Est-ce qu'il faut utiliser DeleteObject à chaque fois ? Il me semble avoir lu que les objets étaient détruits proprement dès qu'ils sont hors de portée. Dans quels cas alors n'est-ce pas le cas ?

c'est le cas ,donc a priori si ce n'est pas des pointeurs pas de pb.
par contre si jamais tu utilises GetDC il faut veiller a faire un ReleaseDC.

**nmarf** · 31/01/2006, 15h00

Envoyé par farscape

c'est le cas ,donc a priori si ce n'est pas des pointeurs pas de pb.
par contre si jamais tu utilises GetDC il faut veiller a faire un ReleaseDC.

Pas de GetDC dans le code, mais par contre il y a des pointeurs. Par exemple un CBrush* dans ce bout de la fonction OnPaint de la classe d'application :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
		HRSRC hRes; 
		HGLOBAL hData, hLockedData;
		CBrush brush;
 
		hRes = ::FindResource(AfxGetResourceHandle(),  MAKEINTRESOURCE(IDB_XX_FOND), RT_BITMAP);
		if (hRes != NULL)
		{
			if (((hData = ::LoadResource(AfxGetResourceHandle(), hRes)) != NULL) && 
			((hLockedData = (HGLOBAL)::LockResource(hData)) != NULL))	  {}
		}
		brush.CreateDIBPatternBrush(hLockedData,		   DIB_RGB_COLORS);
 
		// Select the brush into the device context.
		CBrush* pOldBrush = dc.SelectObject(&brush);
 
		dc.PatBlt( 0, 0, rect.Width(), rect.Height(), PATCOPY    );
 
		dc.SelectObject(pOldBrush);
 
		dcImage.SelectObject(pOldBitmap);
 
		brush.DeleteObject();

IDB_XX_FOND est un fichier BMP en ressource dont on se sert pour remplir le fond de chaque fenêtre.
Est-ce que ce code est critique ?

**findwin** · 01/02/2006, 07h22

Envoyé par nmarf

Est-ce qu'il faut utiliser DeleteObject à chaque fois ? Il me semble avoir lu que les objets étaient détruits proprement dès qu'ils sont hors de portée. Dans quels cas alors n'est-ce pas le cas ?

Moi il me semble que les objets GDI ne sont pas désalloué sans appel à DeleteObject. De plus, la msdn conseille son utilisation dès qu'un objet GDI n'est plus utilisé.

[MFC] Problème de mémoire jamais désallouée

MFC

Discussions similaires

Partager

Partager