¿Debo liberar memoria asignada en una terminación anormal?

Question

Mi programa (un navegador web en modo texto) asigna dinámicamente la memoria.

Hago bloques innecesarios durante el tiempo de ejecución, por supuesto. Y libero todo antes de la finalización normal, de modo que las comprobaciones de fugas de memoria no me den falsos positivos (y sea flexible en caso de que alguna vez se necesiten refactorizaciones importantes).

Ahora, lo que hago no hacer es liberar memoria antes de una terminación anormal. (Actualmente, mi programa termina en señales y después de mallocs/reallocs fallidos.)

Mi pregunta es: ¿Consideras este mal estilo? ¿Debo liberarme de una terminación anormal?

Answer 1

No. Creo que es perfectamente aceptable simplemente levantar las manos y dejar que el SO reclame la memoria después de que el programa termine. Creo que si realmente se trata de una situación anormal y la intención es que el programa finalice, entonces un programa de buen comportamiento debería simplemente limpiar los recursos/bloqueos del disco y salir tan rápido como sea posible.

Answer 2

En mi opinión, no es necesario liberar la memoria en caso de fallo. Cuando finaliza su proceso, el sistema operativo recuperará la memoria, por lo que todo lo que tiene que hacer es salir.

Por otro lado, otros recursos (por ejemplo, archivos abiertos) deben cerrarse o al menos enjuagarse; de ​​lo contrario, es posible que no se almacenen/almacenen incompletos debido al almacenamiento en búfer.

Answer 3

La terminación anormal de su proceso no conduce a bloques de memoria que no pueden ser utilizados por otros procesos (lo que significa que son gratuitos), si fueron asignados por él.

Asignamos/liberamos memoria utilizando OS-directivas para que un sistema operativo sin errores realice un seguimiento de los fragmentos de memoria para cada proceso y los traduzca a un espacio de memoria virtual contiguo. Tras un proceso de muerte, el cargador del sistema operativo lo señala y recupera toda la memoria. Las cosas se complican cuando los procesos comparten memoria.

Los procesos de peering, si no derivados/iniciados/bifurcados por su proceso (por ejemplo, considerar un componente externo que sirve muchos procesos para acceder a recursos multimedia), pueden haber creado memoria (por ejemplo, memoria intermedia) para servir su proceso. Dependiendo de la política de propiedad de estos componentes externos, esa memoria puede no ser libre al morir el proceso servido.

Te aconsejo que intentes auditar toda la memoria cometida antes y después de escenarios de terminación anómalos.

Answer 4

Solo si su sistema operativo no recupera la memoria al finalizar el programa. DOS y su 'memoria adhesiva' es un ejemplo de dicho sistema operativo. En la mayoría de los sistemas operativos modernos, el hecho de no estar libre de una terminación anormal no es un problema.

Answer 5

No, a menos que su programa siempre finalice anormalmente. :) De todos modos, el sistema operativo hace un buen trabajo liberándolo. De hecho, muchos programadores perezosos ni siquiera se molestan en liberar cosas con una terminación normal, pero esto dificulta la detección de otras fugas de memoria (las que son un problema real).

Answer 6

No necesita necesita para reclamar la memoria en la terminación normal excepto para evitar falsos positivos en las herramientas de detección de fugas.

Si su programa termina anormalmente, dependiendo de la causa, puede encontrar que no puede memoria libre. Por ejemplo, un SIGSEGV resultante de un montón corrupto significa que incluso tratar de liberar otras cosas en el montón tal vez sea un ejercicio sin esperanza.

Answer 7

En la terminación anormal, desea hacer el menor procesamiento posible. Minimizar los retoques con el proceso de aborto significará que puede llegar lo más cerca posible del motivo del aborto y cualquier procesamiento posterior puede verse como "contaminante" del proceso, lo que dificulta la depuración.