Проблема с памятью WIN32 (различия между отладкой / выпуском)

Question

В настоящее время я работаю над устаревшим приложением (win32, Visual C ++ 2005), которое выделяет память с помощью LocalAlloc (в поставляемой библиотеке я не могу изменить). Приложение хранит очень большое состояние в фиксированной памяти (создается при запуске с несколькими вызовами LocalAlloc (LPTR, размер)). Я заметил, что в режиме релиза у меня не хватает памяти около 1,8 ГБ, но в режиме отладки, к счастью, она превышает 3,8 ГБ. Я использую XP64 с ключом / 3gb. Мне нужно увеличить объем памяти, используемой в приложении, и я достигаю предела памяти в выпуске (отладка работает нормально). Есть идеи?

Answer 1

Возможно, у вас есть конфигурация отладки, связывающая с / LARGEADDRESSAWARE, и конфигурация выпуска, связывающая с / LARGEADDRESSAWARE: НЕТ (или отсутствует вообще).

Проверьте Linker-> System-> Включить большие адреса в свойствах конфигурации проекта.

Answer 2

Похоже, ваша сборка выпуска также скомпилирована как x86. Если нет, то в вашем коде должно быть что-то, что обрабатывает указатель как 32-разрядные целые числа со знаком, и этот код активен только в Release.

Как проявляется нехватка памяти?

Кроме того, нет причины использовать флаг / 3gb для XP64 при запуске 64-разрядных приложений: в этом сценарии ничего не меняется

Answer 3

Одно предложение: взгляните на базовые адреса библиотек DLL, которые загружаются в пространство процесса в режиме выпуска и отладки, и посмотрите, есть ли большая разница. Возможно, что в случае выпуска есть библиотеки DLL, загруженные по адресам, так что, хотя в целом достаточно свободного места для поддержки вызова LocalAlloc (), не хватает непрерывного адресного пространства для его удовлетворения. (Для надуманного примера предположим, что библиотека DLL загружена в 0x40000000 (1 ГБ), другая - в 0x80000000 (2 ГБ), а другая - в 0xC0000000 (3 ГБ)). Даже если эти DLL действительно малы, процесс не может выделить больше 1 Гб за раз, так как нет свободного непрерывного блока адресного пространства, это достаточно большой).

Вы также можете получить вариант этой проблемы, если распределение памяти происходило в другом порядке и при отладке, и при выпуске.