Как обнаружить, что функция malloc() не будет выполнена?

Question

В моей программе C Я пытаюсь выделить память с функцией таНос(), например:

char *buf = (char *)malloc(size); 

, но проблема в том, что таНос() всегда возвращает ненулевой указатель. Даже если я попытаюсь выделить огромный (размер - 1E + 13) объем памяти, он возвращает действительный buf Указатель. Конечно, после этого программа выйдет из строя.

Но как я могу определить, что запрошенный объем памяти слишком велик и будет недоступен, если возвращается buf Значение не NULL?

Edit:

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

unsigned long size = very_large_calculated_value; 
char *buf = (char *)malloc(size); 
if (buf == NULL) i_know_it_fails; 
... 

но Xcode работает этот код и Buf никогда не NULL независимо просили размера есть. Итак, очень скоро программа аварий. Как я могу обнаружить отказ в распределении памяти, если buf не является NULL, но, очевидно, не подлежит использованию?

Edit:

Для тех, кто отмечен вопрос как дубликат: Там нет ответа на вопрос: «Как я могу обнаружить ошибки распределения памяти?», Потому что решение, как «изменить некоторые параметры в ваша ОС "не является ответом - я прошу C-код обнаруживать ошибку выделения памяти или что-то вроде« невозможно сделать программно ».

Answer 1

malloc() всегда возвращает непустой указатель

Это не совсем верно.

В случае отказа malloc() он вернет NULL. Вам необходимо проверить возвращаемое значение malloc() (указатель) против NULL, чтобы гарантировать, что malloc() является успешным.

Процитирую страницу человека, (курсив мой)

В malloc() и calloc() возвращают указатель на выделенную память, которая надлежащим образом выровнены для любого вида переменной. При ошибке эти функции возвращают NULL. [...]

---

Примечание; [После комментариев]

Если вы говорите о оптимистичных методах распределения, используемых malloc() вернуть указатель, в этом случае нет стандарта способа проверки или предсказать будущего провал, в случае, если malloc() вернул указатель не-NULL. Если вы хотите быть уверенным в доступности памяти, вы можете вместо этого использовать calloc().

Answer 2

Невозможно до предсказать отказ памяти. Единственный способ - проверить возвращаемое значение malloc() для нулевого указателя.

Кажется, что ваш вопрос действительно о памяти overcommit сделан ядром. Использование которого ядро ​​никогда не возвращает нулевой указатель. Значение по умолчанию - всегда overcommit. Таким образом, чтобы отключить его на Linux-подобных систем делают:

echo 2 > /proc/sys/vm/overcommit_memory 

Или вы могли бы сделать то же самое с помощью sysctl:

sysctl vm.overcommit_memory=2 

Оба эквивалентны.

Значение 2 должно гарантировать, что malloc возвращает нулевой указатель в случае, если запрашиваемая память превышает доступную физическую память (плюс пространство подкачки).

Answer 3

Развивая ответ BlueMoon, вот это то, что man page for malloc должен сказать о overcomitting:

ОШИБКИ

По умолчанию Linux следует за выделение стратегии оптимистичной памяти. Это означает, что когда malloc() возвращает не-NULL, не гарантирует, что память действительно доступна. Это очень плохая ошибка. В случае, если окажется, что система находится вне памяти , один или несколько процессов будут убиты печально известным OOM убийцей. В случае Linux используется в условиях, когда он бы менее желательным, чтобы внезапно потерять некоторые случайно выбрал процессы, а кроме того, ядро ​​версии появились достаточно недавно, можно отключить эту overcommitting поведение с помощью команды как # echo 2 > /proc/sys/vm/overcommit_memory
См. Также каталог документации, файлы vm/overcommit-accounting и sysctl/vm.txt.

Answer 4

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

В общем, если удалять все контрольные точки, тогда код запускается как следует, без каких-либо проблем. Но если некоторые точки останова вставлены (влияние их положения в коде для меня неясно), то Xcode становится неустойчивым и падает после функций выделения памяти.