Problème de mémoire WIN32 (différences entre débogage/édition)

Je travaille actuellement sur une application héritée (win32, Visual C++ 2005) qui alloue de la mémoire en utilisant LocalAlloc (dans une bibliothèque fournie je ne peux pas changer). L'application conserve un très grand état dans la mémoire fixe (créée au début avec plusieurs appels à LocalAlloc (LPTR, taille)). Je remarque qu'en mode release je manque de mémoire à environ 1.8gb mais en debug il passe heureusement à plus de 3.8gb. Je cours XP64 avec le commutateur/3gb. J'ai besoin d'augmenter la mémoire utilisée dans l'application et j'atteins la limite de mémoire en sortie (le débogage fonctionne bien). Des idées?Problème de mémoire WIN32 (différences entre débogage/édition)

Source

2009-06-04 Tim Ring

Je réalise que je devrais mettre à jour l'application en 64 bits pour avoir accès à de plus grandes quantités de mémoire fixe. Cependant j'ai besoin de connaître la limitation afin de convaincre mon patron que c'est seulement ainsi je dois prendre une décision: a) Déterminez comment allouer un peu plus de mémoire (approximativement 100mb). Job done -OR- b) Justifiez la mise à jour en 64 bits et demandez aux autres équipes de mettre à jour leurs bibliothèques. –

La configuration de débogage est probablement liée à/LARGEADDRESSAWARE et la configuration Release est liée à/LARGEADDRESSAWARE: NO (ou totalement absente).

Vérifiez Linker-> System-> Activer Large Addresses dans les propriétés de configuration du projet.

Source

2009-06-04 15:07:15 comshak

Merci, c'est .... –

Des sons comme votre version Release sont également compilés en tant que x86. Sinon, il doit y avoir quelque chose dans votre code qui traite le pointeur comme des entiers 32 bits signés et ce code n'est actif que dans Release.

Comment le manque de mémoire se manifeste-t-il?

En outre, il n'y a pas de raison d'utiliser/drapeau 3Go pour XP64 lors de l'exécution des applications 64 bits: il ne change rien dans ce scénario

Source

2009-06-04 11:30:47 Rom

Pas une application 64 bits. –

Ok, je suppose que c'est une application 64 bits puisque vous obtenez 3,8 Go. Oui, vous avez raison, cela peut être fait à partir d'un système d'exploitation de 32 bits sous 64 bits. Alors, comment le manque de mémoire se manifeste-t-il? Je suggère de regarder là d'abord – Rom

À court de mémoire se manifeste par un appel à LocalAlloc renvoyant NULL .... :-) –

Une suggestion: un coup d'oeil aux adresses de base des DLL qui sont chargés dans l'espace de processus en mode release et debug, et voir s'il y a beaucoup de différence. Il est possible que, dans le dossier de publication, des DLL soient chargées aux adresses de sorte que, s'il y a suffisamment d'espace libre pour prendre en charge un appel LocalAlloc(), il n'y a pas assez d'espace d'adressage continu pour le satisfaire. (Pour un exemple artificiel, supposons qu'il y ait une DLL chargée à 0x40000000 (1Gb), une autre à 0x80000000 (2Gb) et une autre à 0xC0000000 (3Gb) .Même si ces DLL étaient vraiment petites, le processus ne pouvait pas allouer plus de 1 Go à la fois, car il n'y a pas de bloc continu d'espace d'adresse laissé libre qui soit assez grand).

Vous pouvez également obtenir une variante de ce problème si les allocations de mémoire se sont produites dans un ordre différent dans le débogage et la publication.

Source

2009-06-04 14:53:13 DavidK

Problème de mémoire WIN32 (différences entre débogage/édition)

Répondre

Questions connexes