Discussion :

[yann458]

Bonjour,
Je constate un phénomène bizarre

J'ai écrit un code qui alloue 500000 pointers et un pointers de 700Mb, bref.

Les 700Mb sont allouer avec succés si je n'ai pas allouer les 500Ko de pointers.
L'allocation des 700Mb echoue si j'ai allouer les 500Ko Pointers car il n'y à plus de place pour l'adressage
Le plus étonnant c'est que l'allocation des 700Mb échoue même si j'ai liberer les 500Ko pointers.

Je ne sais pas ce qu'il se passe pourtant je libére bien les pointers.

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
void *pu[1024*500];
void CmemoryleakDlg::OnBnClickedButton1()
{
 
	int cu=1024*500;
 
	for (int i = 0 ; i < cu;i++)
	{
		__try 
		{
		//BYTE *p=new BYTE[1*1024];
		BYTE *p=(BYTE*)malloc(1024);
		memset(p,0,1024);
		pu[i]=p;
		if (p==NULL)
			p=p;
		}
		__except(MainFilterFunction(GetExceptionInformation()))
		{
		}
	}
	for (int i = 0 ; i < cu;i++)
	{
		free(pu[i]);
		//BYTE *p=(BYTE*)pu[i];
		//delete p;
	}
	BYTE *ii=new BYTE[700*1024*1024]; //CRASH EXCEPTION OUT OF MEMORY
	if (ii==NULL)
			ii=ii;
 
}

Comment faire sinon pour résoudre ce phénoméne ?
car j'ai un projet à moi qui utilise beaucoup de pointers.

Merci.

[Ehonn]

Bonjour

En lisant juste la description, tu devrais avoir quelque chose qui devrait ressembler à ceci :

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
// g++ -Wall -Wextra -Wconversion -Wsign-conversion -std=c++11 -pedantic -fopenmp main.cpp -o main && ./main
// g++ -Wall -Wextra -Wconversion -Wsign-conversion -std=c++98 -pedantic -fopenmp main.cpp -o main && ./main
 
#include <iostream>
#include <vector>
#include <thread>
#include <chrono>
 
 
int main()
{
	std::vector<void *> ps(500000, nullptr);
 
	std::vector<int> tab((700 * 1000 * 1000) / sizeof(int));
 
	std::this_thread::sleep_for(std::chrono::seconds(30)); // Le temps de regarder la consommation mémoire
 
	return 0;
}

Ce programme fonctionne bien et prend environ 700 Mo de mémoire vive.

---

un pointers de 700Mb

C'est pas très bien dit, un pointeur fait toujours sizeof(void *).

Au passage : en C++ (moderne) on n'utilise pas les pointeurs nus (voir memory).

[the Hound]

Bonjour,
Je constate un phénomène bizarre

J'ai écrit un code qui alloue 500000 pointeurs et un pointeurs de 700MB, bref.

Les 700MB sont alloués avec succès si je n'ai pas alloué les 500ko de pointeurs.
L'allocation des 700MB échoue si j'ai alloué les 500ko pointeurs car il n'y a plus de place pour l'adressage
Le plus étonnant c'est que l'allocation des 700MB échoue même si j'ai liberé les 500ko pointeurs.

Je ne sais pas ce qu'il se passe pourtant je libère bien les pointeurs. (Ça ne veut rien dire au passage.)

[...]

Comment faire sinon pour résoudre ce phénomène ?
car j'ai un projet à moi qui utilise beaucoup de pointeurs.

Merci.

C'est cadeau.

[skeud]

(Je vais peut-etre dire une grosse bétise, mais je pense que c'est une idée)

Si je me gourre pas, un pointeur est codé sur 4 octet.
Tu créer deux giga tableau (un de 1024*500 et l'autre de 1024*1024*700).
Donc d'après mes calcul:
1024*500+1024*1024*700 = 734 515 200.
donc 734 515 200 pointeur au total.
multiplié par la taille d'un pointeur (4 octet): 734515200 * 4 = 2 938 060 800. soit presque 3 Giga juste pour les pointeur (sans compter les malloc que tu fais).

Si tu as un PC avec 2Go de ram ou 4Go, je pense que c'est normal que ça plante .

PS: Je tiens à précisé que je ne suis absolument pas sur de mon explication, je cherche d'ou peu provenir le problème et n'étant pas complètement sur de la taille d'un pointeur, mon explication est à prendre comme une indication et non pas comme vérité constante.

[fenkys]

Je confirme. Tu dis une grosse bétise.

Un pointeur dépend de l'architecture et du compilateur. J'ai connu des pointeurs sur 8, 16, 32 et 64 bits.

Par ailleurs 500 000 pointeurs vont représenter plusieurs Mo par eux même mais on est loin du Go. En tenant compte de la mémoire allouée on arrive a environ 500 Mo. C'est beaucoup mais c'est inférieur au Go.

[pepito3364]

ça peut venir d'un problème de répartition de la mémoire.
Tu peux allouer 700 Mo en 700 bloc de 1 Mo par exemple mais pas d'un seul bloc. Si c'est ça, ça vient du fait que tu n'as pas 700 Mo contigu de libre.

Tu es sur quel os et tu compil avec quoi?

[the Hound]

Code :

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

1
2
3
 
if (p==NULL)
    p=p;

Juste comme ça ... pourquoi ?

1024*500+1024*1024*700 = 734 515 200.
donc 734 515 200 pointeur au total.

Sauf qu'il alloue "seulement" 1024*500 pointeurs, les 700MB ne sont pas alloués pour être utilisés sous forme de pointeurs (c'est des BYTE).

ça peut venir d'un problème de répartition de la mémoire.
Tu peux allouer 700 Mo en 700 bloc de 1 Mo par exemple mais pas d'un seul bloc. Si c'est ça, ça vient du fait que tu n'as pas 700 Mo contigu de libre.

Physiquement les blocs mémoire sont rarement contigus ... et le système peut allouer virtuellement des ressources qu'il n'a pas.
Je ne sais pas comment la gestion de mémoire fonctionne sur son OS, mais avec une machine 4Go de RAM de nos jours + le swap du système, c'est étonnant qu'il n'arrive pas à allouer seulement 700Mo (contigus).

Tu es sur quel os et tu compil avec quoi?

Windows je pense, en tout cas le bloc __try/__except le suggère.

[therwald]

Son exécutable est loin de tourner seul sur la machine, alors même sur les "4Go de de nos jours", 700MB contigüs ça ne se trouve pas forcément sous le sabot d'un cheval...

[the Hound]

Son exécutable est loin de tourner seul sur la machine, alors même sur les "4Go de de nos jours", 700MB contigüs ça ne se trouve pas forcément sous le sabot d'un cheval...

Bon, alors pour mettre les choses au clair :
- la mémoire est paginée : divisée en pages d'une taille fixe (4ko par exemple)
- chaque adresse (pointeur) est constitué d'une partie permettant d'identifier la page, ainsi qu'une partie servant d'offset
- la mémoire que l'on voit dans un débogueur ou autre est dite virtuelle. Les adresses, appelées virtuelles également, ne sont pas les "vraies" adresses des données en mémoire.
-> Quand on manipule une adresse, pour lire/écrire en mémoire, la MMU (Memory Management Unit) détermine la page à laquelle appartient l'adresse (je sais, c'est mal dit, mais vous m'avez compris). A chaque page virtuelle est associée une page physique (une "vraie" page en mémoire vive quoi) ; la MMU se contente de récupérer cette "association" et ainsi calculer l'adresse physique. (Exemple : On a une page virtuelle de 4ko, à l'adresse 0, associée à une page physique à l'adresse 0x1000. Alors si p est un pointeur vers 0x2a, il pointe "physiquement" vers 0x1000 + 0x2a = 0x102a.)
-> On peut donc définir un bloc de mémoire virtuellement contigu mais qui sera en réalité physiquement fragmenté.
- chaque processus possède son propre espace virtuel
-> donc physiquement, on peut avoir un gros bordel fragmenté de partout, alors que virtuellement, tous les processus s'exécutent dans leur propre espace virtuel, contigu.
==> Tu pourrais avoir 4Go de RAM, et 50 programmes qui bouffent pile-poil 4Go de RAM, dont un qui t'en prend 1.5 Go et un autre 2Go, et lancés dans un ordre totalement random, il n'y aurait pas de problèmes ... puisque les processus sont, dans tous les cas, fragmentés en mémoire physique.
==> Le fait qu'il y ait d'autres programmes, pour peu qu'ils ne bouffent pas déjà toute la mémoire vive + le swap, importe peu ici.

Par contre, là où ça se complique, c'est si on a pas 700MB de mémoire contiguë dans le même espace virtuel. Si on arrive pas à allouer sur le tas 700MB contigus, d'accord. Mais ce serait étonnant, en effet :
- le système peut utiliser le swap pour libérer de la mémoire physique (qu'il copie sur le disque dur) et ainsi allouer plus de mémoire pour tel programme,
- le système peut allouer des pages virtuelles sans pour autant réserver des pages physiques, après, je sais pas si Windows se sert de ce mécanisme et à quel niveau, Linux lui peut allouer des dizaines de gigas sur des machines qui n'en ont pas,
- le système peut imposer une limite de taille de mémoire pour un programme (c'est sûrement le cas) mais le fait que ça fonctionne chez certain montre que la limite est au-delà des 700MB.

[therwald]

Je vois de quoi tu parles, mais cette "contiguïté" virtuelle" a ses limites: par exemple sous linux (je suis moins certains sous windows) les pages ne sont pas gérées individuellement mais par blocs. Donc le jeu des allocations/libérations de blocs peut parfois conduire à un échec d'allocation alors que de la mémoire apparaît disponible.
Par ailleurs, la mémoire virtuelle effectivement disponible dépend de la taille RAM+swap (sous windows, RAM+espace libre des partitions contenant des pagefiles).
Ça peut être la raison de l'échec d'allocation en l’occurrence.
Autre possibilité: une forte activité disque met de la pression sur le cache de fichier, ce qui diminue la RAM disponible pour les applications (sur certaines versions de windows, la mémoire allouée au cache peut être verrouillée, donc indisponible au moment de la tentative d'allocation).

[the Hound]

Je vois de quoi tu parles, mais cette "contiguïté" virtuelle" a ses limites: par exemple sous linux (je suis moins certains sous windows) les pages ne sont pas gérées individuellement mais par blocs. Donc le jeu des allocations/libérations de blocs peut parfois conduire à un échec d'allocation alors que de la mémoire apparaît disponible.

La pagination est matérielle, ce n'est pas le système qui la gère, mais la MMU et le processeur. Bon ok, on peut créer des pages de 4Mo mais c'est le maximum.

Par ailleurs, la mémoire virtuelle effectivement disponible dépend de la taille RAM+swap (sous windows, RAM+espace libre des partitions contenant des pagefiles).

En réalité, la mémoire virtuelle disponible est égale à la taille de l'espace virtuel adressable. Sur un système avec un adressage virtuel de 64 bits, tu pourras adresser 2 ^ 64 octets, donc la taille de ta mémoire virtuelle sera de 2 ^ 64 octets.
Bien sûr, matériellement, on a pas autant de mémoire (sur les 64-bits en tout cas) et il est à la fois plus simple et plus logique de dire que c'est la taille maximale de mémoire que le système peut techniquement allouer, soit la RAM + le swap. Mais comme je disais précédemment, certains systèmes peuvent allouer "virtuellement" sans réellement réserver de la mémoire, et ainsi fournir des adresses valides qui en réalité ne pointent vers rien.

Autre possibilité: une forte activité disque met de la pression sur le cache de fichier, ce qui diminue la RAM disponible pour les applications (sur certaines versions de windows, la mémoire allouée au cache peut être verrouillée, donc indisponible au moment de la tentative d'allocation).

Possible, mais peu probable ... Les caches ont généralement une taille fixe, et faire un cache d'un 1Go pour le disque dur ça relève de l'absurde. Dit autrement, ça m'étonnerait que Windows ait pris la décision de créer un cache assez gros pour empêcher des applications d'allouer de la mémoire, alors que le débit du disque dur est limité.

[therwald]

La pagination est matérielle, ce n'est pas le système qui la gère, mais la MMU et le processeur. Bon ok, on peut créer des pages de 4Mo mais c'est le maximum.

Ce n'est pas si simple, il existe des étages intermédiaires de niveau système (gestion des pages disponibles vs allouées) qui peuvent introduire des effets de fragmentation.

Possible, mais peu probable ... Les caches ont généralement une taille fixe, et faire un cache d'un 1Go pour le disque dur ça relève de l'absurde. Dit autrement, ça m'étonnerait que Windows ait pris la décision de créer un cache assez gros pour empêcher des applications d'allouer de la mémoire, alors que le débit du disque dur est limité.

En fait non, par défaut le cache croit sous la pression en utilisant toute la RAM disponible à l'instant T, et ne peut pas forcément la libérer instantanément. Vécu sous windows serveur 2008 R2 il y a 5 mois.

En réalité, la mémoire virtuelle disponible est égale à la taille de l'espace virtuel adressable.

Dans la pratique, quand il n'y a plus ni RAM ni swap le système va te jeter dès que tu essaies d'utiliser la mémoire.

[the Hound]

Ce n'est pas si simple, il existe des étages intermédiaires de niveau système (gestion des pages disponibles vs allouées) qui peuvent introduire des effets de fragmentation.

Je sais que la mémoire est divisée en blocs pour les différentes "entités" présentes dans le système (sous Linux) : kernel, modules, vsyscall, etc. Par contre je ne sais plus si cette division est virtuelle ou physique, j'essaierai de voir ça sur le net.
En tous cas ici c'est Windows qui alloue la mémoire, donc on saura pas vraiment comment ça marche en détail.
Bref, je disais que la gestion des pages est réservée au matériel. Le kernel gère peut-être des blocs entiers de pages physiques, mais techniquement, la totalité des pages peut-être "virtualisée" et donc fragmentée.

En fait non, par défaut le cache croit sous la pression en utilisant toute la RAM disponible à l'instant T, et ne peut pas forcément la libérer instantanément. Vécu sous windows serveur 2008 R2 il y a 5 mois.

A voir si la version de Windows a un lien avec le cache (ce qui ne m'étonnerait pas, vu que c'est une édition serveur) ...

Dans la pratique, quand il n'y a plus ni RAM ni swap le système va te jeter dès que tu essaies d'utiliser la mémoire.

Oui.

[yann458]

ça peut venir d'un problème de répartition de la mémoire.
Tu peux allouer 700 Mo en 700 bloc de 1 Mo par exemple mais pas d'un seul bloc. Si c'est ça, ça vient du fait que tu n'as pas 700 Mo contigu de libre.

Tu es sur quel os et tu compil avec quoi?

Je travaille sur visual studio 2008 avec windows XP 4 GB de mémoires.
Ce que je ne comprend pas ,c'est quand je libere mes 500ko pointers avant d'allouer les 700 Mb, et l'allocation des 700 MB echoue.

Quand mes x pointer sont libérer ,la mémoire est contigu ???

[therwald]

Quand mes x pointer sont libérer ,la mémoire est contigu ???

Pas nécessairement. Le système a pu être contraint de diviser des blocs de mémoire pour satisfaire cette allocation, et je ne crois pas qu'il les fusionne à la suite de la libération (d'autant plus qu'il a pu recevoir d'autres demande de mémoire sur les fragments restants).

Les pages ne sont pas allouées une par une, mais par bloc, sous linux au moins (et comme c'est un problème de taille des registres des pages libres et allouées, windows doit rencontrer le même type de contrainte et y apporter sa solution propre)

[yann458]

J'ai tester sur Windows 7 (Seven) 32 et 64 ,
et je n'ai pas le problème d'allocation du pointer ii.

Si vous avez Windows XP et plus de 4 Gb de mémoire, est - ce que pouvez tester le code ?
Je voudrais savoir si cela vient de ma machine ou de l'OS.

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
 
void *pu[1024*500];
void CmemoryleakDlg::OnBnClickedButton1()
{
 
	int cu=1024*500;
 
	for (int i = 0 ; i < cu;i++)
	{
		__try 
		{
		//BYTE *p=new BYTE[1*1024];
		BYTE *p=(BYTE*)malloc(1024);
		memset(p,0,1024);
		pu[i]=p;
		if (p==NULL) //pour debugger
			p=p; //pour dbbugger
		}
		__except(1)
		{
		}
	}
	for (int i = 0 ; i < cu;i++)
	{
		free(pu[i]);
		//BYTE *p=(BYTE*)pu[i];
		//delete p;
	}
	BYTE *ii=new BYTE[700*1024*1024]; //CRASH EXCEPTION OUT OF MEMORY sur Windows XP seulement
	if (ii==NULL)
	{
		MessageBox("Cela ne marche pas");
 	}
}

Merci beaucoup.