There is no point in freeing blocks at end of program? [duplicate]

Answer 1

My personal preference is to not release memory at the end of the program -- the code does nothing useful, but can still have/cause bugs if it's done incorrectly.

At the same time, leaving the memory allocated will trigger reports from almost any automatic leak detector, so if you're using one (or ever might) it's generally better to free the memory to keep real leaks from being lost/ignored. Given their prevalence today, it would be difficult (if even possible) to be sure you'd never use such a thing either.

Answer 2

The best reason to free memory at the end of a program is to find leaks. At least some profilers, like purify, will claim everything is leaked when you don't free before the end of the program. Now, you know it doesn't really matter in the sense that the memory is released to the OS, but it makes it much harder to tell if there was something that you really did intend to free but accidentally did not. This is important for long running processes, like a server process, a daemon, etc where memory leaks can cause major problems. For simple programs that do a job and then exit right away, I really don't think it matters if you free explicitly.

Answer 3

(This is a highly subjective answer, so take it how you will.)

I think it's good practice in case you end up adding to the process, in which case you might want to free up the memory after all.

I think it's always good to hold dynamic memory only as long as you need it, and then freeing it up. I usually like to write free in my code immediately after I write malloc, and then put whatever code I need in between.

Answer 4

It's very much a common practice to just exit a program without freeing it's memory.

Whether it's a best practice is certainly up for a discussion - quite so often a main() in one program evolves to a function call in another bigger program and when that happens you wish you got your memory (de)allocation straight. Then again for small programs it can be just a hazzle and extra unneeded work.

Answer 5

There is stuff I try very hard not to free explicitly. Inter-thread comms object pools, for example. I want the OS to free these 'cos it'll always stop all my threads, (those that might still writing to the objects), first before freeing process memory.

If I don't do this, I get all those problems of trying to terminate threads that are stuck on blocking calls or running loops. Can't be bothered with all that hassle :)

Rgds, Martin

Answer 6

I've taken a lot of heat for this, but my position is that putting effort into freeing memory just before program exit should be Considered Harmful. For one thing it's extra code to maintain and debug - but probably not too much, so that's only a small issue. The much larger issue is practical effects.

Suppose you have a long-lived program that's allocated complex/deep data structures - as a good example, think of a web browser. It's likely that much of this data has not been used in a while, and further that it's been swapped to disk. If you just exit, the swapped-out data on disk is simply marked unused and never touched again. But if you walk through all your program's data structures to free them, you will touch every single swapped-out page, causing:

• disk access to read the swapped-out data
• eviction of other programs' actually-important data from memory
• and corresponding disk access to swap out said data belonging to other programs.

All of this wastes:

• the user's time
• wear on the HDD (or even worse, on SSD/flash)

This behavior is easily observable if you overload your system with enough bloated desktop apps (Firefox, OpenOffice, GIMP, etc. or Windows equivalents) to get it swapping, then try to close one of them. You'll spend several seconds (maybe even ~30 sec it the swapping is bad enough) waiting for it to exit. If the program had just called exit directly (after checking for unsaved documents and whatnot) it would have closed immediately.