5

Possible Duplicate:
Is freeing allocated memory needed when exiting a program in C

I was reading the page "Freeing Memory Allocated with malloc" and ran across this sentence:

There is no point in freeing blocks at the end of a program, because all of the program's space is given back to the system when the process terminates.

I realize what the author is trying to say, but shouldn't the sentence be:

There is no point in freeing blocks at the end of a program, because all of the program's space is given back to the system when the process terminates, although you should still make sure you program frees all malloc'ed memory before exiting.

Or is it common practice to not de-allocate memory before the termination of the process?

Community
  • 1
  • 1
Samaursa
  • 16,527
  • 21
  • 89
  • 160
  • 1
    See http://stackoverflow.com/questions/5612095/is-freeing-allocated-memory-needed-when-exiting-a-program-in-c/5612119#5612119 – Blagovest Buyukliev Jun 14 '11 at 16:44
  • Why make sure to free all memory before the program exists if all memory will be freed anyway? To me that seems like needless. It would be interesting to know if there are any reason why you should, though! – rzetterberg Jun 14 '11 at 16:49
  • @Blagovest: Ah! Similar question. In my defence, I did do a search but may have missed this. I vote for a close as well. – Samaursa Jun 14 '11 at 16:54
  • 1
    @Ancide: code re-use is one reason. If your `main` function, or something it calls to do the heavy lifting, "leaks" memory, then you can't use that code as part of something else. Maybe you don't want to, which is OK, but it does mean you have to somehow draw a distinction between code that's fit for general use, and code that should only be called in a process that will exit shortly after the call returns. – Steve Jessop Jun 14 '11 at 18:13

6 Answers6

44

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.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • 1
    That is a very interesting answer, and I must select this as the correct one (sorry nos!). I wish (as I always do) I could select more than one answer. – Samaursa Jun 14 '11 at 17:34
  • 6
    The fact that I'm checking SO as I'm shutting down at the end of the day means I pretty much have to give this +1 - performance of the shutdown operation is well worth considering. – Steve Jessop Jun 14 '11 at 18:27
  • 3
    By the way, another consideration in multi-threaded programs is that correctly freeing all memory at program close may require non-trivial synchronization. If you get this wrong and free some memory that another part of your cleanup routine later tries to access, you'll invoke undefined behavior. At best the program will crash, but worse things could happen, and either way it's a bad user experience. Just plain exiting can thus save you a big chunk of difficult-to-debug program logic. – R.. GitHub STOP HELPING ICE Aug 05 '11 at 17:40
  • How difficult do you think this is to do when much of a program’s memory allocations are not by the main program but by libraries it calls? There may be buffers to be flushed, network partners to be informed, and so on, so you cannot simply call `exit` but must call cleanup routines for those libraries. And most of those libraries probably just have some routine to close its stuff in a routine way, both flushing buffers and deallocating memory (and other wind-up tasks) rather than a routine that says “We are exiting, just wind-up the essential stuff.” So how much benefit can be gained? – Eric Postpischil May 27 '20 at 12:39
  • @EricPostpischil: You really don't need to call cleanup routines for them, unless they deal with state that needs to be saved. You just `exit` and throw away their state. Library deallocation/close/etc. functions are treated exactly like `free` here: something you do if you want to recover the resources they're using while continuing to run, not something you dogmatically do on exit. – R.. GitHub STOP HELPING ICE May 27 '20 at 17:12
5

(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.

Platinum Azure
  • 45,269
  • 12
  • 110
  • 134
4

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.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
2

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.

nos
  • 223,662
  • 58
  • 417
  • 506
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.

frankc
  • 11,290
  • 4
  • 32
  • 49
  • 2
    One way you can still achieve this is by just enabling your "free-everything-at-exit" code in debug builds. – R.. GitHub STOP HELPING ICE Jun 14 '11 at 16:58
  • 1
    @R..: sounds reasonable to me. Treat "not freeing everything at exit" as an optimization, so write the code but then decide later whether to actually call it or not based on measurable performance. Personally I'd want to do it both ways in debug builds, though, so that any bugs in the "not-free" case still get exercised under debug conditions. However unlikely it sounds that *not* running code would be a bug, but we can imagine that some component tries to flush an app-level buffer at cleanup time. OK, so the flush might fail, but perhaps we'd still want to attempt it. – Steve Jessop Jun 14 '11 at 18:18
2

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

Martin James
  • 24,453
  • 3
  • 36
  • 60