¿Puedo confiar en que malloc devolverá NULL?

Question

Leí que en los sistemas Unix, malloc puede devolver un puntero que no sea NULL, incluso si la memoria no está realmente disponible, e intentar usar la memoria más adelante provocará un error. Como no puedo detectar ese error al buscar NULL, me pregunto qué tan útil es verificar NULL en absoluto.

En una nota relacionada, Herb Sutter dice que manejar los errores de memoria C++ es inútil, porque el sistema sufrirá espasmos de paginación mucho antes de que realmente ocurra una excepción. ¿Esto también se aplica al malloc?

Answer 1

Citando Linux manuals:

Por defecto, Linux sigue una estrategia de asignación de memoria optimista. Esto significa que cuando malloc() devuelve no NULL, no hay garantía que la memoria esté realmente disponible. Este es un error realmente malo. En caso de que el sistema se quede sin memoria, uno o más procesos serán asesinados por el infame asesino OOM. En el caso de Linux se emplea en circunstancias en las que sería menos deseable para perder repentinamente algunos al azar procesos escogidos, y por otra parte la versión del núcleo es suficientemente reciente, se puede desactivar este comportamiento La sobrecarga usando un comando como:

# echo 2 > /proc/sys/vm/overcommit_memory 

Debe comprobar el retorno NULL, especialmente en sistemas de 32 bits, ya que el espacio de direcciones del proceso podría agotarse mucho antes de la RAM: en Linux de 32 bits, por ejemplo, los procesos de usuario pueden tener espacio de direcciones utilizable de 2G 3G a diferencia de más de 4G de RAM total. En sistemas de 64 bits podría ser inútil verificar el código de retorno malloc, pero podría considerarse una buena práctica de todos modos, y hace que su programa sea más portátil. Y, recuerde, desreferenciar el puntero nulo mata su proceso ciertamente; algunos intercambios pueden no doler mucho en comparación con eso.

Si sucede malloc para volver NULL cuando se trata de asignar sólo una pequeña cantidad de memoria, entonces hay que tener cuidado cuando se trata de recuperarse de la condición de error como cualquier posterior malloc puede fallar también, hasta que hay suficiente memoria disponible.

El operador de C++ predeterminado new es a menudo un contenedor sobre los mismos mecanismos de asignación empleados por malloc().

Answer 2

En Linux, puede de hecho no se basan en malloc regresar NULL si hay suficiente memoria no está disponible debido a la estrategia de asignación excesiva del núcleo, pero aún debe comprobar que debido a que en algunas circunstancias mallocse retorno NULL, por ejemplo, cuando solicita más memoria de la disponible en la máquina en total. La página de manual de Linux malloc(3) llama a la sobreasignación "un error realmente malo" y contiene consejos sobre cómo desactivarlo.

Nunca he escuchado que este comportamiento también se produzca en otras variantes de Unix.

En cuanto a los "espasmos de paginación", eso depende de la configuración de la máquina. Por ejemplo, tiendo a no configurar una partición de intercambio en las instalaciones de Linux para portátiles, ya que el comportamiento exacto que teme podría matar el disco duro. Todavía me gustaría que los programas C/C++ que ejecuto verifiquen los valores de retorno malloc, proporcionen los mensajes de error apropiados y, cuando sea posible, limpien ellos mismos.

Answer 3

Para ver esto desde un punto de vista alternativo:

"malloc puede devolver un puntero no nulo, incluso si la memoria no está realmente disponible" no significa que siempre devuelve un valor no nulo. Puede haber (y habrá) casos en los que se devuelve NULL (como ya se dijo), por lo que este control es necesario.

Answer 4

La comprobación de la devolución de malloc no le ayuda mucho por sí solo para que sus asignaciones sean más seguras o menos propensas a errores. Incluso puede ser una trampa si esta es la única prueba que implementa.

Cuando se invoca con un argumento de 0, la norma permite malloc devolver un tipo de dirección única, que no es un puntero nulo y al que no tiene derecho de acceso, sin embargo. Por lo tanto, si solo prueba si el resultado es 0 pero no prueba los argumentos en malloc, calloc o realloc, es posible que encuentre un segfault mucho más tarde.

Esta condición de error (memoria agotada) es bastante rara en entornos "alojados". Por lo general, tienes problemas mucho antes de que te molestes con este tipo de error. (Pero si está escribiendo librerías en tiempo de ejecución, es un kernel hacker o un generador de cohetes, esto es diferente, y allí la prueba tiene perfecto sentido)

Las personas tienden a decorar su código con capturas complicadas de esa condición de error que abarcan varios líneas, haciendo perror y cosas así, que pueden tener un impacto en la legibilidad del código.

Creo que este "comprobar el retorno de malloc" está muy sobreestimado, a veces incluso defendido de forma bastante dogmática. Otras cosas son mucho más importantes:

• siempre inicializar variables, siempre. para las variables del puntero esto es crucial, deje que el programa se cuelgue bien antes de que las cosas se pongan feas. los miembros punteros no inicializados en struct s son una causa importante de errores que son difíciles de encontrar.
• Compruebe siempre el argumento para malloc y compañía si esto es una constante de tiempo de compilación como sizof toto no puede haber un problema, pero siempre asegurarse de que su vector de asignación maneja el caso cero correctamente.

Una cosa fácil de comprobar si hay retorno de malloc es envolverlo con algo como memset(malloc(n), 0, 1). Esto solo escribe un 0 en el primer byte y se bloquea muy bien si malloc tuvo un error o n fue 0 para empezar.