Should I free allocated memory on abnormal termination?

Question

Hello everybody!

My program (a text-mode web browser) is dynamically allocating memory.

I do free unneeded blocks during runtime, of course. And I do free everything before normal termination - so that memory leak checkers won't give me false positives (and to be flexible should major refactorings ever become needed).

Now, what I do not do is freeing memory before abnormal termination. (Currently, my program terminates on signals and after failed mallocs/reallocs.)

My question is: Do you consider this bad style? Should I free on abnormal termination?

Answer 1

No. I think it's perfectly acceptable to simply throw up your hands and let the OS reclaim the memory after the program terminates. I think if this is truly an abnormal situation and the intention is to have the program terminate, then a well-behaved program should simply clean up any disk resources/locks, and exit as quickly as possible.

Answer 2

In my opinion freeing the memory on crash isn't necessary. When your process terminates, OS will reclaim the memory, so all you have to do is exit.

On the other hand, other resources (e.g. open files) should be closed or at least flushed -- if not, they may not be stored/stored incomplete because of the buffering.

Answer 3

Abnormal termination of your process does not lead to memory blocks that cannot be used by other processes (effectively meaning they are free), if they were allocated by it.

We allocate/free memory using OS-directives so that a non-buggy OS keeps track of mem chunks for each process and translates them into a contiguous virtual memory space. Upon a process-death, OS loader signals it, and all memory gets recalled. Things get complicated when processes share memory.

Peering processes, if not derived/launched/forked by you process (e.g. consider an external component serving many processes to access multimedia resources), may have created memory (e.g. buffer) to serve your process. Depending on the policy of ownership of these external components, that memory might not be free upon served-process death.

I advise you to try audit all memory committed before and after abnormal termination scenarios.

Answer 4

Only if your OS doesn't reclaim memory on program termination. DOS and its 'sticky memory' is an example of such an OS. On most modern OS not free()'ing on abnormal termination is a non-issue.

Answer 5

No, unless your program always terminates abnormally. :) Anyway, the OS does a fine job freeing it up. In fact many lazy programmers don't even bother freeing things up with normal termination - but this makes detecting other memory leaks difficult (the ones that are a real problem).

Answer 6

You don't need to reclaim memory on normal termination except to obviate false positives in leak detecting tools.

If your program terminates abnormally, depending on the cause, you may find that you can't free memory. For instance, a SIGSEGV resulting from a corrupted heap means that even trying to free other stuff on the heap maybe a hopeless exercise.

Answer 7

On abnormal termination you want to do as little processing as possible. Minimizing tinkering with the aborting process will mean you can get to as close to the reason for the abort as possible and any further processing can be seen as "contaminating" the process thus making it more difficult to debug.