Попытка выделить максимально возможную память для обработки

Question

Попытка выделить максимально возможную память для обработки

0

Это относится к Windows XP, и приложение разрабатывается в C++ (VS2010).

Я хочу, чтобы мое приложение продолжало выделять память, пока оно не достигнет своих пределов без каких-либо проблем. Но если он выделяет целые 2 ГБ (максимальный предел для 32-разрядной Windows), он перезаписывает пространство для стека и, в конце концов, сбой. Как этого можно избежать? (Кстати, я использую malloc и new для выделения памяти)

Из "Частных байтов", "Виртуальных байтов" и "Рабочего набора", я считаю, что я должен отслеживать "Виртуальные байты". Но я не совсем уверен в этом. (Является ли это "Виртуальные байты" или "Частные байты" при касании 2 ГБ, мы можем быть уверены, что коснулись предела?)
Если это "виртуальные байты", я должен контролировать, я не уверен, в каком поле _PROCESS_MEMORY_COUNTERS_EX отображены виртуальные байты
Чтобы приложение работало безопасно и плавно, сколько памяти я должен держать в стороне? (Это просто размер стека = количество потоков x Размер стека в потоке или есть что-то большее)

Atul 16 июнь 2014, в 16:46

Источник

1

Почему ты бы так поступил?
Victor 16 июнь 2014, в 14:36
0

@Victor: Просто использовать максимально возможную память ...?
Atul 16 июнь 2014, в 14:38
1

Проверьте возвращаемое значение malloc (и в соответствии с настройками компиляции также новое возвращаемое значение). NULL (или исключение) существуют по этой причине. Вы даже не можете проверить свободную память только потому, что вам нужно непрерывное пространство. Расчет не так прост из-за различных накладных расходов.
Adriano Repetti 16 июнь 2014, в 14:38
0

@Adriano Repetti: при таком подходе он переполняет стек
Atul 16 июнь 2014, в 14:39
1

Вы не должны держать память в стороне. Вы должны распределять память по мере необходимости, следить за ошибкой выделения памяти и обрабатывать ее (malloc возвращает NULL при ошибке памяти).
IdeaHat 16 июнь 2014, в 14:41
0

Мы уверены, что не нужно беспокоиться о размере стека, или я что-то здесь упускаю? Я злюсь после того, как вижу, что мое приложение работает нестабильно, если я просто продолжаю выделять ресурсы (просто проверяя NULL)
Atul 16 июнь 2014, в 14:44
2

Вы абсолютно уверены, что не ваш код приложения перезаписывает ваш стек, когда malloc начинает давать сбой? Или, может быть, библиотека, которую вы используете?
Mike Andrews 16 июнь 2014, в 14:51
2

Если распределение завершится неудачно, оно не будет перезаписывать стек ... вы просто получите NULL (и это может повредить приложение или вызвать нарушение доступа). Переполнение стека, вероятно, вызвано чем-то другим (например ... динамический стек не сможет расти, если нет непрерывного блока свободной памяти).
Adriano Repetti 16 июнь 2014, в 14:52

Показать ещё 6 комментариев

Теги:

c++

c

memory

memory-management

2 ответа

Ещё вопросы

@Victor: Просто использовать максимально возможную память ...?
Проверьте возвращаемое значение malloc (и в соответствии с настройками компиляции также новое возвращаемое значение). NULL (или исключение) существуют по этой причине. Вы даже не можете проверить свободную память только потому, что вам нужно непрерывное пространство. Расчет не так прост из-за различных накладных расходов.
@Adriano Repetti: при таком подходе он переполняет стек
Вы не должны держать память в стороне. Вы должны распределять память по мере необходимости, следить за ошибкой выделения памяти и обрабатывать ее (malloc возвращает NULL при ошибке памяти).
Мы уверены, что не нужно беспокоиться о размере стека, или я что-то здесь упускаю? Я злюсь после того, как вижу, что мое приложение работает нестабильно, если я просто продолжаю выделять ресурсы (просто проверяя NULL)
Вы абсолютно уверены, что не ваш код приложения перезаписывает ваш стек, когда malloc начинает давать сбой? Или, может быть, библиотека, которую вы используете?
Если распределение завершится неудачно, оно не будет перезаписывать стек ... вы просто получите NULL (и это может повредить приложение или вызвать нарушение доступа). Переполнение стека, вероятно, вызвано чем-то другим (например ... динамический стек не сможет расти, если нет непрерывного блока свободной памяти).

cup · Answer 1 · 2014-06-16T12-28-00.000Z

Вы можете получить доступ к 3Gb, изменив файл boot.ini

[boot loader]
timeout=5
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS 
[operating systems] 
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect /3GB

Затем вам нужно изменить свой исполняемый файл, используя editbin (также поставляется с экспресс-версией)

editbin /LARGEADDRESSAWARE xxx.exe

Это работает для меня. Если это не работает, необязательный заголовок отсутствует. Я не знаю, как вы заставляете заголовок быть там.

Если у вас много времени - это длинная история http://www.dansdata.com/askdan00015.htm

Это его приложение, поэтому он может захотеть использовать / LARGEADDRESSAWARE напрямую в качестве опции компоновщика.

GeoAoe · Answer 2 · 2014-06-16T12-05-00.000Z

0

Менеджер программы не оставляет места для вашего стека и других данных. Вы можете вызвать malloc и new, пока они не вернут 0 (NULL). Я думаю, что рабочий набор - это переменная, которую вы должны контролировать.

GeoAoe 16 июнь 2014, в 12:05

0

При выделении 2 ГБ я заметил, что мое приложение становится нестабильным и выдает ошибки «переполнения стека». Также «Рабочий набор» - это выделение, выделенное физической памяти, и это может быть больше уже выделенной памяти, которая могла бы быть выгружена на диск.
Atul 16 июнь 2014, в 14:42
0

Вы можете позвонить Malloc, и я думаю, что не работает вместе
Yann 16 июнь 2014, в 14:47
0

Можете ли вы опубликовать свой исходный код, чтобы я мог проверить его на своем компьютере?
GeoAoe 17 июнь 2014, в 07:04
0

@GeoAoe, извините за задержку с ответом. Это слишком большой, чтобы оставлять сообщения. Я экспериментирую с этим. Я предполагаю, что проблема в другом и приводит к ошибке «переполнение стека». Кроме того, при использовании около 2 ГБ памяти при запуске нового потока также R6016 - not enough space for thread data ошибка R6016 - not enough space for thread data
Atul 24 июнь 2014, в 04:24

Показать ещё 2 комментария