¿Es necesario comprobar si hay NULL después de asignar memoria, cuando el kernel utiliza memoria de sobre-compromiso


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

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

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

De hecho, el kernel de Android utiliza un exceso de memoria (no estoy seguro del valor, me encantaría sé(valor de sobreasignación) y su significado). Parte del código fuente del framework(C/C++) en Android (podría ser de 3rd party) no comprueba NULL ni captura bad_alloc después de las asignaciones. Me estoy perdiendo algo?

Hay algunos hilos en SO con respecto a la memoria de exceso de compromiso, pero ninguno de ellos resolvió mi confusión.

EDITAR: Si se está empleando un exceso agresivo, NULL no se devolverá(suposición 1). Cuando no hay memoria física disponible y encima en intentar acceder la memoria asignada (escribir en la memoria asignada), OOM matará algún proceso y asigna memoria para la aplicación hasta que se mata a su vez(suposición 2). En cualquier caso, no veo ninguna necesidad de cheking NULL (la memoria se asigna o el proceso se mata). ¿tengo razón en mis suposiciones?
la Portabilidad no es una preocupación para esta pregunta.

Author: elmarco, 2010-02-12

5 answers

Sí, aún debe verificar si hay fallas devueltas por malloc. En un entorno que sobrecompone memoria no podrá detectar y recuperarse de fallos debido a que el entorno se queda sin almacenamiento físico requerido cuando escribe en partes del espacio de direcciones que se han asignado a su programa por una llamada anterior a malloc.

Sin embargo, este no es el único problema que causaría que un malloc fallara en un entorno tradicional. Una solicitud para un bloque particularmente grande de memoria cuando el espacio de direcciones de su programa se ha fragmentado puede fallar incluso si hay potencialmente suficiente memoria física total para satisfacer la solicitud. Debido a que no hay un rango contiguo de espacio libre de direcciones malloc debe fallar. Este tipo de fallo debe ser señalado por malloc devolviendo NULL, independientemente de que el entorno esté o no sobreactuando la memoria.

 37
Author: CB Bailey,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-02-17 11:56:53

Debe comprobar el valor devuelto para NULL cada vez. Cualquier función de biblioteca puede fallar. Incluso fclose () do (en el recurso compartido NFS desconectado, y el error de fclose del archivo NFS significa, que los datos no se guardaron).

La mayor parte del software está mal escrito y no contiene todas las comprobaciones.

Malloc no puede devolver algo que no sea NULL o pointer. Todo o nada. No puedes obtener 1 byte de malloc si pides 10.

 8
Author: osgx,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-02-15 15:01:08

Sería aconsejable verificar religiosamente NULL en todas las llamadas a funciones que puedan devolver NULL, independientemente de si el núcleo tiene memoria sobre-confirmable o no.

Este siguiente segmento de código muestra cómo verificar si la llamada a malloc funcionó 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, por nombrar solo algunas, devolverán un NULL si falla.

Espero que esto ayude, Atentamente, Tom.

 2
Author: t0mm13b,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-02-17 11:37:52

Bueno...en Linux, dado que la memoria no está respaldada por páginas (inicialmente) y solo crea respaldo de páginas después de la primera lectura/escritura, el sistema operativo siempre tendrá éxito para darle memoria (a menos que haya agotado el espacio de direcciones, algo que no es posible en sistemas de 64 bits). Entonces, si se queda sin memoria y no puede darle la memoria prometida, OOM killer simplemente matará su aplicación o alguna otra aplicación para darle el respaldo de página que necesita. Así que si haces la comprobación NULA o no, la salida es la misma, una accidente.......

 1
Author: Asif Bahrainwala,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-04-24 04:37:22

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

Mucho antes de que malloc fallara, el sistema operativo ya había encontrado muchos problemas.

 -5
Author: Shaoquan,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-07-17 14:58:11