Problème de libération de la mémoire virtuelle

**Martial72** · 08/02/2013, 13h34

Bonjour à tous,

Mon problème est le suivant.
J'ai réalisé une application en C++ sous Visual Studio 10 sous windows XP 32bit.
Cette application doit créer une quantité très importante d'objets en mémoire de petite taille (environ 20 Ko).
J'ai donc ajouté à mon code un bloc try/catch pour intercepter les dépassements mémoires.
Lorsque l'occupation mémoire atteint 2Go, les allocations échouent. Une exception est générée. L'application la capture et libère la mémoire.
L'objectif est de pouvoir gérer ces situations et garder la stabilité de l'appli.
Or il semble qu'après avoir libérer toutes les ressources allouées par l'application, la mémoire virtuelle n'est pas libérée.
En utilisant la fonction GlobalMemoryEx(), on s'apperçoit que la mémoire disponible n'est que de quelques méga.
Il est ensuite impossible de réallouer un espace mémoire de plus d'une dizaine de méga.

Pour mieux comprendre voici un code d'exemple reproduisant le problème :

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
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
// AllocationErr.cpp : définit le point d'entrée pour l'application console.
//
 
#include "stdafx.h"
//#include <iostream.h> 
#include <vector> 
#include "AllocationErr.h"
 
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
 
using namespace std;
 
void ReportMemory()
{
	MEMORYSTATUSEX statex;
 
	statex.dwLength = sizeof (statex);
	GlobalMemoryStatusEx (&statex);
 
	HANDLE heap = GetProcessHeap();
	SIZE_T size =  HeapCompact(heap, 0);
 
	BOOL validated = HeapValidate(heap, 0, NULL);
 
	TRACE("GlobalMemoryStatusEx:\n");
	TRACE(" + TotalVirtual : %0.1lf Mo\n", statex.ullTotalVirtual / (1024.0 * 1024.0));
	TRACE(" + AvailVirtual : %0.1lf Mo\n", statex.ullAvailVirtual / (1024.0 * 1024.0));
	TRACE(" + Process mem load : %0.1lf %%\n", (1.0 - (double) statex.ullAvailVirtual / (double) statex.ullTotalVirtual) * 100.0);
	TRACE(" + TotalPageFile : %0.1lf Mo\n", statex.ullTotalPageFile / (1024.0 * 1024.0));
	TRACE(" + AvailPageFile : %0.1lf Mo\n", statex.ullAvailPageFile / (1024.0 * 1024.0));
}
 
int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
    TRACE("Before allocation\n");
    ReportMemory();
 
    const unsigned int taille_bloc = 10* 1024, nb_blocs_max = (3U * 1024U * 1024U * 1024U / taille_bloc);
    int i = 0;
 
    char ** p = NULL;
 
    try
    {
        p = new char *[nb_blocs_max];
 
        memset(p, 0, nb_blocs_max * sizeof(char *));
 
        for(i = 0; i < nb_blocs_max; i++)
        {
            p[i] = new char[taille_bloc];
        }
    }
    catch (CMemoryException* e)
    {
        e->Delete();
 
        TRACE("After the program ran out of memory\n");
        ReportMemory();
 
        for(i = 0; i < nb_blocs_max; i++)
        {
            if(p[i])
            {
                delete [] p[i];
            }
        }
 
        delete [] p;
    }
 
    TRACE("After freeing memory\n");
    ReportMemory();
 
    char * t = NULL;
    try
    {
        const unsigned int taille_max = 30 * 1024 * 1024;
        t = new char[taille_max];
    }
    catch (CMemoryException* e)
    {
        TRACE("Memory allocation failed\n");
        e->Delete();
 
        if(t)
        {
            delete [] t;
        }
    }
 
    return 0;
}

Le résultat afficher est le suivant :

Before allocation
GlobalMemoryStatusEx:
+ TotalVirtual : 2047.9 Mo
+ AvailVirtual : 2016.8 Mo

+ Process mem load : 1.5 %
+ TotalPageFile : 5198.6 Mo
+ AvailPageFile : 3172.9 Mo

After the program ran out of memory
GlobalMemoryStatusEx:
+ TotalVirtual : 2047.9 Mo
+ AvailVirtual : 4.5 Mo

+ Process mem load : 99.8 %
+ TotalPageFile : 5198.6 Mo
+ AvailPageFile : 1155.2 Mo

After freeing memory
GlobalMemoryStatusEx:
+ TotalVirtual : 2047.9 Mo
+ AvailVirtual : 5.7 Mo

+ Process mem load : 99.7 %
+ TotalPageFile : 5198.6 Mo
+ AvailPageFile : 3170.8 Mo

Avez vous une idée ?
Vous trouverez également en pièce jointe le projet Visual 10 ...

**LinuxUser** · 08/02/2013, 13h58

Plusieurs remarques:

* pourquoi ce melange de C et C++ ?
* attention, Windows ne respecte pas la casse mais d'autres système si, donc ton code ne compilera pas sous Linux par exemple, notamment à cause de "Ressource.h" qui est inclus en temps que "ressource.h".
* j'ai regardé vite fais mais j'ai l'impression que tu libères la mémoire uniquement si une exeption est levée.
* juste pour info, où est définie "MEMORYSTATUSEX" ?
* attention quand tu fais "memset(p, 0, nb_blocs_max * sizeof(char *));" car sizeof(char *) = taille d'un pointeur de char en octet.

**gbdivers** · 08/02/2013, 14h03

Bonjour et bienvenue sur le forum

Pourquoi ne pas avoir tout simplement une politique de gestion de la mémoire qui n'attend pas que la mémoire soit saturée avant de libérer les ressources inutilisés ?

**Martial72** · 08/02/2013, 14h43

Envoyé par LinuxUser

Plusieurs remarques:

* pourquoi ce melange de C et C++ ?
* attention, Windows ne respecte pas la casse mais d'autres système si, donc ton code ne compilera pas sous Linux par exemple, notamment à cause de "Ressource.h" qui est inclus en temps que "ressource.h".
* j'ai regardé vite fais mais j'ai l'impression que tu libères la mémoire uniquement si une exeption est levée.
* juste pour info, où est définie "MEMORYSTATUSEX" ?
* attention quand tu fais "memset(p, 0, nb_blocs_max * sizeof(char *));" car sizeof(char *) = taille d'un pointeur de char en octet.

Le C++ étant dérivé du C, il est normal que l'on retrouve du C dans du code C++. Mais là n'est pas le problème. Il s'agit d'un problème purement Windows et notamment Windows XP 32 bits. J'ai ajouté le projet dans un zip si besoin.

MEMORYSTATUSE est une structure standard de l'API windows.

l'instruction "memset(p, 0, nb_blocs_max * sizeof(char *));" est correcte car il s'agit d'un tableau de pointeur char. L'objectif est ici de stresser le gestionnaire de mémoire en allouant une multitude de blocs de quelques méga que l'on stocke dans le tableau.

La désallocation est en effet réalisée dans le cas où l'exception pète. Mais dans mon exemple, elle pète forcément (car il s'agit juste d'un exemple pour montrer le défaut)

Voilà ... si quelqu'un à une idée, je suis prenneur ...

**Martial72** · 08/02/2013, 14h46

Envoyé par gbdivers

Bonjour et bienvenue sur le forum

Pourquoi ne pas avoir tout simplement une politique de gestion de la mémoire qui n'attend pas que la mémoire soit saturée avant de libérer les ressources inutilisés ?

Bonjour,

Dans mon cas j'utilise des fonctions issues de bibliothèques que je ne maitrise pas et qui créent des objets en mémoire dont je ne connais pas forcément la taille auparavant ... Et malheureusement c'est à moi de gérer le tout ...

**Arzar** · 08/02/2013, 14h49

Bonjour,
Le code a l'air correct. (mais je n'ai pas pu tester avec mon VS2010 express qui ne supporte pas les MFC)

Envoyé par Martial72

Or il semble qu'après avoir libérer toutes les ressources allouées par l'application, la mémoire virtuelle n'est pas libérée.
En utilisant la fonction GlobalMemoryEx(), on s'apperçoit que la mémoire disponible n'est que de quelques méga. Il est ensuite impossible de réallouer un espace mémoire de plus d'une dizaine de méga.

Je n'ai pas compris comment tu détermines qu'il est "ensuite impossible de réallouer un espace mémoire de plus d'une dizaine de méga". Tu as essayé d'afficher le numéro de bloc qui provoque l'exception dans les deux cas ?

**white_tentacle** · 08/02/2013, 14h53

Ça sent un problème de fragmentation mémoire à plein nez.

Le code que tu as donné initialement reproduit exactement le problème, y compris en release ? Ou c’est seulement un exemple ?

**Martial72** · 08/02/2013, 14h57

Envoyé par Arzar

Bonjour,
Le code a l'air correct. (mais je n'ai pas pu tester avec mon VS2010 express qui ne supporte pas les MFC)

Je n'ai pas compris comment tu détermines qu'il est "ensuite impossible de réallouer un espace mémoire de plus d'une dizaine de méga". Tu as essayé d'afficher le numéro de bloc qui provoque l'exception dans les deux cas ?

Bonjour,

Dans la dernière partie du code je réalloue 30 Méga dans le pointeur t.
L'allocation échoue à tous les coups, alors que je viens de libérer la totalité de la mémoire allouée ...

Remarque En utilisan ProcessExplorer, je peux voir que la mémoire privée de l'application a été libérée mais en regardant la mémoire virtuelle, on s'apperçoit qu'elle est toujours à 2 Go d'occupation (et ce même après avoir libéré la mémoire). ???

**Martial72** · 08/02/2013, 15h14

Envoyé par white_tentacle

Ça sent un problème de fragmentation mémoire à plein nez.

Le code que tu as donné initialement reproduit exactement le problème, y compris en release ? Ou c’est seulement un exemple ?

Après vérification, le code reproduit le même problème en Release et en Debug.
J'ai également pensé à un problème de fragmentation. Mais lorsque je libère la mémoire dans mon exemple, la documentation windows dit que le tas est "recompacté". Je suppose qu'il défragmente automatiquement le mémoire. Je n'ai pas trouvé de fonction de l'API Windows permettant de réaliser manuellement cette opération ...

**phi1981** · 08/02/2013, 16h27

Je serais curieux de savoir ce qui se passe si tu réecris ton programme en utilisant malloc()/free() plutôt que new[] delete[].
evidemment, malloc() ne generera pas d'exception donc il faudra plutôt tester sa valeur de retour, le programme ne peut pas fonctionner de la même manière.

**koala01** · 09/02/2013, 14h18

Salut,

Envoyé par Martial72

Le C++ étant dérivé du C, il est normal que l'on retrouve du C dans du code C++.

Je ne peux que m'inscrire en faux intégral sur ce passage!!!

S'il est vrai que C++ "hérite" de C, ce sont deux langages qui n'ont plus rien à voir, et il serait plus que temps que les gens commencent tout doucement à l'assimiler!

A l'heure actuelle, le seul cas dans lequel il est envisageable de mélanger C et C++, c'est si tu dois t'interfacer avec une bibliothèque ou une interface C.

En dehors de ce cas, tu ne devrais absolument jamais mélanger les deux dans un fichier ou dans une fonction. Rien ne t'empêche d'avoir des fichiers C et des fichiers C++ dans un seul et même projet, bien que je déconseille malgré tout cette pratique, mais, si tu écris du code C++, tu as plus qu'intérêt à n'utiliser que C++

Cela aurait, entre autre, l'intérêt de te permettre d'utiliser pleinement le RAII (Ressource Acquisition Is Initialisation) même si, en l'occurrence, c'est surtout l'effet inverse qui t'intéresserait

**Mat.M** · 09/02/2013, 19h54

Envoyé par Martial72

Après vérification, le code reproduit le même problème en Release et en Debug.
J'ai également pensé à un problème de fragmentation. Mais lorsque je libère la mémoire dans mon exemple, la documentation windows dit que le tas est "recompacté". Je suppose qu'il défragmente automatiquement le mémoire. Je n'ai pas trouvé de fonction de l'API Windows permettant de réaliser manuellement cette opération ...

salut je pense que c'est une des explications au problème
Sinon sous Windows XP il y a le fichier pagefile.sys,je suppose que c'est un fichier de "swap"
Si tu fais des grosses allocations,l'OS écrit dedans.
Le fait de fermer ton programme ne désalloue pas forcément les écritures dans pagefile.sys

http://support.microsoft.com/kb/99768/en-us

**Martial72** · 11/02/2013, 09h18

Je viens d'essayer mon programme (32 bits) sur un OS windows 7 64 bits. Le problème est identique.
J'ai poussé l'analyse en changeant new et delete par des malloc et des free. Et le problème reste. En effet le new et le malloc sous windows utilise la même fonction de l'API HeapAlloc.
J'ai ensuite essayé d'allouer des blocs de 10Ko jusqu'à atteindre une occupation mémoire de 1.8 Go pour ne pas provoquer une saturation mémoire. Puis j'ai libéré la mémoire que je venais d'allouer. J'ai alors essayé d'allouer un bloc de 300 Mo. L'opération s'est soldée par un échec alors que la mémoire disponible était de 1.9 Go.
Si il s'agit d'un problème de fragmentation, cela ne devrait impacter que la mémoire allouée. Or ici ce n'est pas le cas.
Je sèche vraiment sur ce problème ...

**Arzar** · 11/02/2013, 11h30

Salut,
J'ai pu reproduire le problème avec le code donné dans le premier post ce weekend avec vs2012 + windows 8 et je pense en avoir trouvé l'origine.

Déjà une petite précision, avec visual studio new appelle malloc qui appelle HeapAlloc et delete appelle free qui appelle HeapFree, donc le comportement est identique que ce soit avec new/delete et avec malloc/free

il semblerait que l'origine du problème proviennent du design de la Heap sous windows. Le thread suivant explique en détails le souci :

http://www.tech-archive.net/Archive/.../msg00189.html

(Attention seul les interventions de Pihilip Borghesani et Jeffrey Tan sont pertinentes, les autres n'ont pas compris le problème et pose des questions ou proposent des "solutions" complètement à coté de la plaque)

En résumé, la heap sous windows utilisé par le runtime C se comporte différemment en fonction de la taille du bloc alloué. Les petites allocations (<500ko) sont allouées dans les segments de la heap alors que pour les grosses allocations (>500ko) la heap délèguent en fait le boulot à la fonction VirtualAlloc. Le problème ne se manifeste qu'avec les petites allocations et il est du au fait que HeapAlloc réserve des plages d'adresses dans la mémoire virtuelle mais ne relâche pas ces plages lors d'un HeapFree !

Du coup on se trouve dans une situation assez paradoxale car après avoir tout libéré avec delete la heap est effectivement vide, ce que l'on vérifie avec HeapCompact (qui renvoie la taille du plus grand bloc libre dans le tas) qui renvoie une taille très grande (plus d'un go chez moi), mais au final les futures allocations dans le tas échoue car toutes les adresses de la mémoire virtuelle sont épuisées (On a que 2go d'adressage en 32 bits).

On peut vérifier que le pb ne se manifeste qu'avec des allocations de petite taille en changeant dans ton code la valeur de taille_bloc = 10* 1024 à taille_bloc = 10* 1024 * 1024. Dans ce cas, on passe la barrières des 500ko et tout ce passe comme prévu, on peut à nouveau utiliser new après avoir fait tous les delete sans se prendre d'exception.

Malheureusement la réponse d'un employé de Microsoft est assez décourageante... (en substance "By Design")

have consulted this issue internally, and it seems this is by design,
below is the feedback:
"The issue here is that the blocks over 512k are direct calls to VirtualAlloc, and everything else smaller than this are allocated out of the heap segments. The bad news is that the segments are never released (entirely or partially) so ones you take the entire address space with small blocks you cannot use them for other heaps or blocks over 512 K. If your program exposes such an usage pattern, the easiest workaround would be to use a separate heap for the short-term small allocations, and destroy the heap when you're done with it (and it would be faster too, instead of freeing blocks one by one)."

Hope this helps

Best regards,
Jeffrey Tan
Microsoft Online Partner Support

Donc malheureusement je crois qu'il n'y a que trois options dans ton cas, pas forcement très satisfaisantes :
- Ne faire des new que sur des ojets de taille supérieur à 500ko... bon

- Coder une heap custom, puis surcharger new et delete pour utiliser cette heap custom...
- Passer en 64bits, où l'on a plus le problème d'adressage limitée à 2go.

J'ai fait le test sur un OS 64 bits (et surtout *compilé pour 64 bits* sinon ça ne change rien. Pour compiler en 64 bits voir ici : http://blogs.msdn.com/b/tolong/archi...plication.aspx). Le problème disparaît.

**jblecanard** · 11/02/2013, 12h26

Envoyé par Arzar

Donc malheureusement je crois qu'il n'y a que trois options dans ton cas, pas forcement très satisfaisantes :
- Ne faire des new que sur des ojets de taille supérieur à 500ko... bon

- Coder une heap custom, puis surcharger new et delete pour utiliser cette heap custom...
- Passer en 64bits, où l'on a plus le problème d'adressage limitée à 2go.

Ou une solution intermédiaire : faire des allocations "custom" uniquement pour ces objets, avec des in place new bien placés. Je suppose que tous ces blocs ne sont pas des données libres et sont traités via une interface comme un ensemble de données cohérent et représentant quelque chose de concret. L'implémentation de ce truc pourrait gérer l'allocation un peu particulière dans l'objet sans forcément aller jusqu'à une réécriture de new et de delete avec une heap custom.

**Martial72** · 11/02/2013, 12h34

Envoyé par Arzar

Salut,
J'ai pu reproduire le problème avec le code donné dans le premier post ce weekend avec vs2012 + ....

Merci beaucoup pour tes explications. Je n'avais pas trouvé d'information sur le sujet. je pense donc que je vais me recoder un gestionnaire mémoire et surcharger les opérateurs new et delete pour mes besoins ...

Encore bravo et merci pour tes conseils ....

Problème de libération de la mémoire virtuelle

C++

Discussions similaires

Partager

Partager