Discussion :

[camboui]

J'ai un programme qui tourne sans soucis depuis des années sous Win2000, XP, Win Server 2003, etc. En 32 bits donc, compilé depuis des sources C++.

Ce même programme (je veux dire exactement le même binaire 32bits) se plante lors d'une allocation de 125MB environ sous Win Server 2008/64. Comme s'il n'y avait pas assez de mémoire !
Au total le prg consomme en pointe 960MB (d'après le "task manager" ou "gestionnaire de tache"), bien en dessous de la limite de 2GB.

Je me suis dit qu'il pouvait y avoir une fragmentation de la mémoire qui empêche l'allocation du gros bloc, mais alors pourquoi je n'ai jamais eu ce problème sous Win32, même avec 1GB de mémoire réel (avec swap disque et donc lenteur, mais jamais plantage).

Bref, je ne comprend pas. J'ai pourtant bien droit un espace de mémoire virtuelle de 2GB, non ? (la machine possède 16Gb réel).
Comprend pas...

Merci pour votre aide.

[AF_2.8]

Tu as recompilé ton code en 64bits?

[camboui]

Ce n'est pas une option à court terme.
Les sources sont compilées avec un compilateur des années '90. Il ne suffit de dire "target is 64 bits".


En gros je demande si vous avez déjà rencontré ce cas ou un OS64 serait plus limité en resource mémoire pour les applications 32 que sous un vrai OS32 (Windows64 vs Windows32 en l'occurence).

[AF_2.8]

Perso je n'ai pas rencontré se problème, mais celà pourrait éventuellement cacher un bug qui n'apparaissait pas avant.
De ma propre expérience chaque vois que je fais évoluer ma plateforme, je découvre des problèmes qui n'apparaissaient pas avant.

[camboui]

L'endroit où ça plante est parfaitement localisé, c'est dans le premier appel à un push_back() peu après l'exécution de ce code:

Code :

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

1
2
3
4
5
6
std::vector<SProperty> f_propArr;
 
...
	f_propArr.reserve(f_prepropArr.size());
	std::cout << "\tvector<SProperty> capacity: " << f_propArr.capacity()
		<< " * " << sizeof(SProperty) << " = " << f_propArr.capacity()*sizeof(SProperty) << std::endl;

A l'affichage/log on voit bien que l'allocation de mémoire dans le std::vector.reserve() a échoué.

[3DArchi]

Tu peux réduire à un expl minimal qui reproduise.
Parce que je vois : sois le changement de plateforme révèle un bug ailleurs dans votre code, sois un problème windows ?

[camboui]

Bon, et bien voici la preuve par 9.
Un petit bout de code:

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
#include <iostream>
#include <iomanip>
#define QLOOP 20
 
int main(int argc, char* argv[])
{
	unsigned i, c=0;
	char *p[QLOOP];
	for(i=0; i<QLOOP; ++i)
	{
		c+=120*1024*1024;
		cout << "loop " << dec << i+1 << " (" << c << ")" << endl;
		(cout << "\tfail\r").flush();;
		p[i]=new char[120*1024*1024];
		if (0==p[i])
			throw;
		cout << "\tbase " << hex << (void *)(p[i]) << endl;
	}
	for(i=0; i<QLOOP; ++i)
		delete [] p[i];
	return 0;
}

Voici le résultat sous XP32 (1GB de mémoire physique):

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
loop 1 (125829120)
        base 0x00420020
loop 2 (251658240)
        base 0x07C30020
loop 3 (377487360)
        base 0x0F440020
loop 4 (503316480)
        base 0x16C50020
loop 5 (629145600)
        base 0x1E460020
loop 6 (754974720)
        base 0x25C70020
loop 7 (880803840)
        base 0x2D480020
loop 8 (1006632960)
        base 0x34C90020
loop 9 (1132462080)
        base 0x3C4A0020
loop 10 (1258291200)
        base 0x43CB0020
loop 11 (1384120320)
        base 0x4B4C0020
loop 12 (1509949440)
        base 0x52CD0020
loop 13 (1635778560)
        base 0x5A4E0020
loop 14 (1761607680)
        base 0x61CF0020
loop 15 (1887436800)
        base 0x69500020
loop 16 (2013265920)
        base 0x70D10020
loop 17 (2139095040)
        fail
abnormal program termination

Voici le résultat sous Server64 (8GB de mémoire physique):

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
loop 1 (125829120)
        base 0x004F0020
loop 2 (251658240)
        base 0x07D00020
loop 3 (377487360)
        base 0x0F510020
loop 4 (503316480)
        base 0x16D20020
loop 5 (629145600)
        base 0x1E530020
loop 6 (754974720)
        base 0x25D40020
loop 7 (880803840)
        base 0x2D550020
loop 8 (1006632960)
        base 0x34D60020
loop 9 (1132462080)
        base 0x3C570020
loop 10 (1258291200)
        base 0x43D80020
loop 11 (1384120320)
        base 0x4B590020
loop 12 (1509949440)
        base 0x52DA0020
loop 13 (1635778560)
        base 0x5A5B0020
loop 14 (1761607680)
        base 0x61DC0020
loop 15 (1887436800)
        base 0x6B2D0020
loop 16 (2013265920)
        fail
abnormal program termination

On va manifestement moins loin en 64bits.
Je suis perplexe...

[koala01]

Salut,

Il faut faire attention au fait que, même si le système en lui-même est 64 bits, les limitations d'une application 32bits sont celles... d'une application 32 bits.

Ce sur quoi j'essaye d'attirer ton attention, c'est que, si ton application est compilée en 32 bits, il n'y a rien à faire, tous tes pointeurs, toutes tes adresses mémoires seront limités (sans prendre en compte les autres limites du système, bien sur ) à une taille de... 32 bits.

Si tu te trouve déjà avec 20 fois 120 Mb, il n'est pas surprenant outre mesure qu'il devienne difficile (toutes choses étant égales) de trouver un nouvel espace de 120Mb contigus inutilisés

La limite propre du système n'aura strictement rien à voir: comment veux tu arriver à retrouver une adresse (codée sur 32 bits) libre si, a priori, tu as déjà fait le tour de toutes les adresses disponibles

EDIT: (en plus, je ne suis pas du tout sur que, lorsqu'il fonctionne en mode "compatible 32bits", windows ne suive pas les limites qui étaient imposées sur ses version 32bits... mais je ne peux pas l'affirmer )

[AF_2.8]

Perso sous 7 64bits 8Go RAM j'ai testé ton code en le compilant sous l'environnement Qt creator (donc en 32 bits), et j'avoue que moi sa plante au bout de 14 boucles. Pour l'instant j'ai pas eu le temps de cherché plus loin ...

[3DArchi]

Salut,
Est-ce que ça (Memory Limits for Windows Releases )répond à ta question ?

[camboui]

Mon application consomme beaucoup de mémoire, plus que je ne pensais, au point de fleurter avec les limites octroyées sous 32bits.
Visiblement, ces limites sont de 2GB (ou 4 avec IMAGE_FILE_LARGE_ADDRESS_AWARE) moins 100, 200, 300MB en fonction du contexte, de la taille du code, des DLL dépendantes, du noyau, etc.
En user mode.
J'ai aussi fait le test en compilant en static ou en dynamic, un peu moins de mémoire dispo encore dans ce dernier cas.
En gros, en fonction du système on peut avoir 200-300MB de plus ou de moins (toujours en dessous de la limite de 2GB). C'est ce que montre le petit test.
J'ai aussi fait le test en compilant avec IMAGE_FILE_LARGE_ADDRESS_AWARE. Le programme boucle 32 fois au lieu de 16 (#define QLOOP 40).

Bref, le contexte de la nouvelle machine me prive de 100 ou 200MB par rapport à la précédante. Finalement c'est pas plus mal, cela m'a permit de constater que le prg consomme trop de mémoire, il faudra tôt ou tard y faire quelque chose. En attendant j'ai fais quelques petites optimisations qui repoussent la prochaine échéance.

Bon, alors je sais ce qu'est un prg 32bits, quand même
Par contre je ne connais pas en détail ce que le système met à ma disposition, Windows en l'occurence. Enfin... quel Windows ?
3Darchi, ton lien est instructif. On y apprend que le "meilleur" des windows n'utilisera jamais un adressage sur plus de 41bits (2TB) mais les pointeurs en mémoire, eux, en feront toujours 64.