¿Es necesario verificar si hay NULL después de asignar memoria, cuando el kernel usa memoria de sobrecompromiso?

Question

Es una práctica general comprobar si hay NULL (si la memoria se asignó correctamente) después de malloc(), algo como

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

con la sobrecompromiso de memoria habilitada en el kernel, ¿existe la posibilidad de obtener NULL?¿Debo seguir la práctica de comprobar religiosamente NULL para cada asignación?¿Malloc devolverá NULL a pesar del agresivo mecanismo de sobrecompromiso (supongo que el valor es 1)?

De hecho, el kernel de Android utiliza sobrecompromiso de memoria (no estoy seguro del valor, me encantaría saberlo (valor de sobrecompromiso) y su significado).Parte del código fuente del marco (C/C++) en Android (puede ser de terceros) no busca NULL ni detecta bad_alloc después de las asignaciones.¿Me estoy perdiendo de algo?

Hay algunos hilos en SO sobre compromiso excesivo de memoria, pero ninguno resolvió mi confusión.

EDITAR: Si se emplea un compromiso excesivo agresivo, no se devolverá NULL (supuesto 1).Cuando no hay memoria física disponible y se intenta acceder a la memoria asignada (escribir en la memoria asignada), OOM finalizará algún proceso y asignará memoria para la aplicación hasta que se elimine a su vez (supuesto 2).En cualquier caso, no veo ninguna necesidad de verificar NULL (se asigna memoria o se elimina el proceso).¿Estoy en lo cierto en mis suposiciones?
La portabilidad no es una preocupación para esta pregunta.

Answer 1

Sí, aún debe buscar errores devueltos por malloc. En un entorno que overcommits memoria que no será capaz de detectar y recuperarse de los fallos debido al entorno de ejecución de almacenamiento físico requerido cuando se escribe en partes del espacio de direcciones que se han asignado a su programa por una llamada previa a malloc.

Sin embargo, este no es el único problema que podría causar un malloc falle en un entorno tradicional. La solicitud de un particular gran bloque de memoria cuando el espacio de direcciones del programa se ha fragmentado puede fallar, incluso si no es potencialmente suficiente memoria física total para satisfacer la solicitud. Debido a que no hay una gama contigua de espacio de direcciones malloc libre debe fallar. Este tipo de fallo debe ser señalado por malloc volver NULL, si o no el medio ambiente se Sobrealojamiento memoria.

Answer 2

Debe comprobar el valor de retorno para NULL cada tiempo. Cualquier función de biblioteca puede fallar. Incluso fclose () hacer (en desconectado compartido NFS, y el error de fclose de medios de archivos NFS, que los datos no se ha guardado).

La mayor parte del software está mal escrita y no contiene todos los controles.

malloc no puede devolver algo distinto de NULL o puntero. Todo o nada. No se puede obtener a partir de 1 byte malloc si pide 10.

Answer 3

Sería aconsejable comprobar NULL religiosamente en todas las llamadas de funciones que pueden devolver NULL, independientemente de que el núcleo tiene más de confirmable memoria o no.

Este segmento de código siguiente muestra cómo comprobar si la llamada a malloc funcionaba o no ...

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

Las operaciones de archivo, las operaciones de memoria para nombrar sólo unos pocos volverán un valor NULL en caso de fallo.

Espero que esta ayuda, Atentamente, Tom.

Answer 4

bueno ... en Linux ya que la memoria no está respaldado página (inicialmente) y sólo crea respaldo de la página después de la primera lectura / escritura, el sistema operativo siempre tendrá éxito para darle la memoria (a menos que agotado el espacio de direcciones, algo que no es posible en sistemas de 64 bits). Así que si se queda sin memoria y no se le puede dar la memoria prometido, asesino OOM se acaba de matar a su aplicación o alguna otra aplicación para darle el respaldo de página que necesita. Así que si lo hace el cheque nulo o no, la salida viene es lo mismo, un accidente .......

Answer 5

No, no hay necesidad de comprobar el resultado de malloc.

Mucho antes de malloc fallaría, el sistema operativo ya se había encontrado con un montón de problemas.

"OOM-Killer y overcommit" sería una mejor opción.

¿Qué? El sistema operativo no soporta "OOM-Killer y overcommit"?

Esta es la razón por la que debe cambiar a Linux (o Android)!