Подтвердить что ты не робот

Нужно ли проверять NULL после выделения памяти, когда ядро ​​использует память overcommit

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

void *ptr = malloc(10);    
if (ptr != NULL) {  
  // do some thing usefull  
} else {  
 // no memory. safely return/throw ...  
}  

с включенным избыточным ядром в ядре, есть ли шанс получить NULL? Должен ли я следовать практике религиозной проверки NULL для каждого распределения? Будет ли malloc возвращать NULL, несмотря на агрессивный механизм overcommit (я думаю, значение 1)?

На самом деле ядро ​​Android использует избыток памяти (не уверен в значении, хотел бы знать его (превышение значения) и его значение). Некоторый код исходного кода (C/С++) в Android (может быть сторонним) не проверяет наличие NULL и не вылавливает bad_alloc после выделения. Я что-то пропустил?

В SO есть некоторые потоки в отношении памяти overcommit, но никто из них не разрешил мое замешательство.

EDIT: Если применяется агрессивный overcommit, NULL не будет возвращен (предположение 1). Когда нет физической памяти и не пытается получить доступ к выделенной памяти (запись в выделенную память), OOM убьет некоторый процесс и распределит память для приложения, пока он не будет убит по очереди (предположение 2). В любом случае я не вижу необходимости в том, чтобы набрать NULL (выделение памяти или удаление процесса). Я прямо в своих предположениях?
Переносимость не является проблемой для этого вопроса.

4b9b3361

Ответ 1

Да, вы должны проверить наличие ошибок, возвращаемых malloc. В среде, которая переназначает память, вы не сможете обнаружить и восстановить из-за сбоев из-за нехватки физической памяти, требуемой при записи в части адресного пространства, которые были выделены вашей программе предыдущим вызовом malloc.

Однако это не единственная проблема, которая приведет к сбою malloc в традиционной среде. Запрос на особо большой блок памяти, когда адресное пространство вашей программы стало фрагментированным, может потерпеть неудачу, даже если имеется потенциально достаточная общая физическая память для удовлетворения запроса. Поскольку не существует непрерывного диапазона свободного адресного пространства malloc, он должен выйти из строя. Этот тип отказа должен сигнализироваться malloc возвратом NULL, независимо от того, является ли среда чрезмерной памятью.

Ответ 2

Вы должны проверить возвращаемое значение для NULL каждый. Любая функция библиотеки может выйти из строя. Даже fclose() do (при отключенном общем доступе NFS и ошибке от fclose файла NFS означает, что данные не были сохранены).

Большая часть программного обеспечения плохо написана и не содержит всех проверок.

malloc не может вернуть ничего, кроме NULL или указателя. Все или ничего. Вы не можете получить 1 байт от malloc, если вы попросите 10.

Ответ 3

Было бы целесообразно проверять NULL религиозно по всем вызовам функций, которые могут возвращать NULL, независимо от того, имеет ли ядро ​​чрезмерную память или нет.

Этот следующий фрагмент кода ниже показывает, как проверить, работает ли вызов malloc или нет...

void *ptr = malloc(10);
if (ptr != NULL){
   /* Do something here with ptr */
}else{
   /* Do something here if it fails */
}

Операции с файлами, операции с памятью, которые будут отображаться, но некоторые возвратят NULL при сбое.

Надеюсь, это поможет, С наилучшими пожеланиями, Том.

Ответ 4

Нет, нет необходимости проверять результат malloc.

Задолго до того, как malloc потерпит неудачу, операционная система уже столкнулась с множеством проблем.