42

Should I free all my mallocated memory when I am exiting program in the due of error?

something = (char**) malloc (x * sizeof(char*));
for (i = 0; i < x; i++)
    something[i] = (char*) malloc (y + 1);

...

if (anything == NULL) {
   printf("Your input is wrong!");
   // should I free memory of every mallocated entity now?
   exit(1);
} 
else {
   // work with mallocated entities
   ...
   free(something); // it must be here
   system("pause);
}
Lundin
  • 195,001
  • 40
  • 254
  • 396
Lucfia
  • 621
  • 1
  • 7
  • 14
  • 3
    I see no reason. OS will do that for you. – Aleksandar Makragić Apr 12 '16 at 21:09
  • 11
    But it is a good habit to clean after yourself. – Eugene Sh. Apr 12 '16 at 21:10
  • 4
    While it is true that the OS will do it for you, what happens when OP adds a new function to do some processing and then another and then another? Or worse, when the new guy (gal) comes on and starts modifying? My advice, free all allocated memory. Oh, and do not cast the results of your allocations. Ever. – KevinDTimm Apr 12 '16 at 21:11
  • Thank you! When I am testing my program, and I forgot to free it, OS will deallocate it for me too? – Lucfia Apr 12 '16 at 21:17
  • Possible duplicate of [Is Object Releasing on Program Exit Really Needed?](http://stackoverflow.com/questions/347338/is-object-releasing-on-program-exit-really-needed) – technosaurus Apr 12 '16 at 21:24
  • 1
    Possible duplicate of [Is leaked memory freed up when the program exits?](http://stackoverflow.com/questions/2975831/is-leaked-memory-freed-up-when-the-program-exits) – Adrian McCarthy Apr 12 '16 at 21:34
  • 1
    One advantage of not freeing is that if your program has a large number of allocations, then freeing on exit will slow down your application's exit sequence. – M.M Apr 12 '16 at 21:53
  • @M.M it probably will, yes, unless the shutdown code deadlocks or segfaults first. – Martin James Apr 13 '16 at 12:02
  • Possible duplicate of [What REALLY happens when you don't free after malloc?](https://stackoverflow.com/questions/654754/what-really-happens-when-you-dont-free-after-malloc) – S.S. Anne Oct 20 '19 at 23:23
  • 1
    @KevinDTimm, why shouldn't we cast the result of allocations? – MrObjectOriented Apr 21 '20 at 11:46

5 Answers5

52

This is actually a really hard, imponderable question.

Pro (in favor of freeing everything before exit):

  • no bugs or memory leaks later if code is rearranged
  • no false positives from valgrind or memory leak checker
  • no memory leaks if you're running under a buggy OS, or no OS at all

Con (just exit, don't worry about freeing everything):

  • freeing everything can be a lot of work
  • freeing everything can introduce bugs and crashes
  • your OS really, really ought to reclaim all resources for you when you exit

And, one more point (not sure if it's a pro or a con): on the majority of systems, calling free does not return memory to the Operating System (only exiting does that).

In the end, you will have to decide which of these pros and cons matters most for you. Different programmers on different projects under different circumstances will reach different conclusions; there is no one-size-fits-all answer here.

See also this previous Stack Overflow question. See also question 7.24 in the C FAQ list.

Steve Summit
  • 45,437
  • 7
  • 70
  • 103
  • 8
    Well said! Restating a comment I made below: if you're a newbie, in general, make "free it manually" the habitual instinct (less dangerous habit), and make "leave it to the OS" be a conscious, informed, case-by-case decision. The decision-making process for that will become instinct over time. Otherwise, you'll habitually forget to free your mallocs and clean up your dangling pointers, and you're subsequently signing up for surprise UBs the next time you change your code in such a way that failing to free the memory now *matters*. – CodeMouse92 Apr 12 '16 at 21:40
  • 1
    @JasonMc92 while that sounds nice, it is building extra unreliablity into today's code. Explicitly freeing memory at app termination is not free, not safe and not always possible. It's usually unnecessary extra code that needs to be tested and debugged, over, and over again, on all OS versions. It's uni cargo-cult mantras like 'you must always explicitly free before terminating' that result in the many apps we have both used that will not shut down cleanly and quickly:( – Martin James Apr 13 '16 at 12:00
  • 3
    As I said on the other (longer) comment chain: the link in the answer backs up my point. By and large, **freeing manually** (overall, not just at program end) is usually an issue of stability (short- and long-term), while **not freeing manually** is usually an issue of performance, and we all know the adage: "Premature optimization is the root of all evil." (-Donald Knuth). **Free by habit, decide not to by choice,** not to ensure OS gets the memory back, but to prevent errors when we refactor code later. Beyond that, we have a "holy war" and had probably best agree to disagree. – CodeMouse92 Apr 13 '16 at 14:50
  • 1
    I found running under no OS being the ultimate no memory leaks. When your exit chainloads the next program it comes up just as yours did and sees all the memory in the computer as randomly initialized free memory. – Joshua Aug 16 '18 at 22:06
  • 1
    You could argue that if it's a lot of work to free, then the program is poorly designed. – klutt Aug 04 '20 at 07:52
15

You should always free allocated memory before you exit. As already mentioned in other answers, this will minimize warnings from static- or dynamic analysis tools etc.

But the real reason why you should always do this, is because freeing often exposes dormant run-time bugs in your application.

If you have a bug somewhere that causes memory corruption or changes pointer addresses, that bug may stay silent and dormant. Until you change something completely unrelated to the bug and thereby shuffle around the memory layout. Then suddenly you get a crash and you'll have no idea why, because the bug isn't even located in the code you just added.

By freeing the memory, you provoke such bugs to surface. Because if there is anything wrong with the heap or with the pointers pointing at the heap, then you will often get a crash at the point where you call free(). Which means that you have a severe bug somewhere, that you need to find before shipping the program.

Lundin
  • 195,001
  • 40
  • 254
  • 396
13

You don't need to free memory before program termination. Terminating the program in any way causes all memory to be deallocated automatically.

fuz
  • 88,405
  • 25
  • 200
  • 352
  • 7
    In a hosted environment with proper process isolation, and ignoring things like shared memory... – EOF Apr 12 '16 at 21:13
  • I agree with this answer on a technical level, but not on a practical level. I agree with Eugene and Kevin in the question comments: it's better to clean up after oneself *anyway*. Otherwise, a later code rewrite could sufficiently rearrange things to trigger UBs that wouldn't have been present before. – CodeMouse92 Apr 12 '16 at 21:14
  • 2
    I want to down vote this answer as these are the kinds of things that eventually bite us. I didn't, but I want to. – KevinDTimm Apr 12 '16 at 21:14
  • 3
    @JasonMc92 I disagree. On error exit, it's often very hard or impossible to correctly clean up all the memory as data structures may be corrupted. Attempting to clean things up is a futile endeavour. – fuz Apr 12 '16 at 21:18
  • 1
    @FUZxxl, yes, there are situations where one can't necessarily clean up, but that doesn't leave an excuse for intentionally skipping clean-up that one *can* clean, for the reason I cited above. Just because you can't scrub behind the fridge doesn't mean you don't mop the floor. – CodeMouse92 Apr 12 '16 at 21:19
  • If a program wishes to exit because it has detected a problem that may have impacted memory-management, trying to free stuff will just make things worse:( On non-trivial OS, let the OS do it - it's really, really good at it, much, much better than user code. – Martin James Apr 12 '16 at 21:19
  • 1
    @JasonMc92 excuse? It's a very good reason indeed. Unless there is an overriding reason to do so, it's pointless effort at best, slower on average and dangerous at worst to try and duplicate in user code what the OS can easily do on its own. – Martin James Apr 12 '16 at 21:22
  • @JasonMc92 Why clean the floor if you tear down the house? There is zero purpose in freeing memory right before terminating the program. Terminating the program frees all memory anyway, freeing it manually beforehand is redundant and useless. – fuz Apr 12 '16 at 21:23
  • ..and may be impossible. If the allocation is buried in an opaque library, you're stuft. Also, unlike the OS, user code is unable to guarantee stopping all process threads in any state before attempting to free memory. If a thread is CPU-looping, you cannot stop it with user code. The OS can, and does. – Martin James Apr 12 '16 at 21:25
  • 3
    I think what I'm saying is this: we need to **default to manual clean up**, and make a conscious decision to leave it to the OS when appropriate. If we default to "let the OS to it" and have to make a conscious decision to clean up ourselves, we are more likely to "forget" things that lead to dangling pointers and the like (especially during code rewriting), and thereby yield UBs. The decision to **not** clean up manually needs to be an *educated intentional choice*, as I'm sure it is for ya'll by habit. Less experienced coders need to **form** that habit. – CodeMouse92 Apr 12 '16 at 21:34
  • 3
    The way to form that habit, of course, is to habitually plan for manual cleanup when possible, and when they realize it will be difficult/impractical/dangerous, making the conscious decision of "I had better leave this to the operating system to clean up." With the opposite habit, many a newbie coder will decide "I don't need to free my malloc. The OS will do it!" and fail to notice that they're asking for a swarm of nasal demons five lines later. – CodeMouse92 Apr 12 '16 at 21:38
  • Absolutely. The question is, do you want the person to learn that a stove light indicates the burner is hot by letting them touch it, or by discovering that they can't boil water when the light's off? Oversimplified example, of course. In that scenario, you *tell them*, but the basic idea is: do they learn from getting injured or from taking the long, non-injurious way around? Forming the habit the way I described leaves them to discover things by the unintentional scenic route when there was a shorter way (always a good learning opportunity), instead of by self-inflected UB injury. – CodeMouse92 Apr 12 '16 at 22:20
  • @JasonMc92 If you don't understand the importance of proper memory management by getting burned by not doing it right at first, you will never understand the importance and write weird code. – fuz Apr 12 '16 at 22:25
  • @FUZxxl really? That's not how I learned about proper memory management. I learned by following the warning "free your mallocs!" the first time, and discovering the rarer cases where freeing them weren't possible/practical down the road after chasing my tail for a bit. I prefer that way of learning - I picked up some cool knowledge while I chased my tail, and it was less stressful than getting a glut of UBs. (I might add, mine is typically Valgrind pure on the first shot.) – CodeMouse92 Apr 12 '16 at 22:26
  • I might add, [this Q&A](http://c-faq.com/malloc/freeb4exit.html) backs up my point. By and large, **freeing manually** is usually an issue of stability (short- and long-term), while **not freeing manually** is usually an issue of performance, and we all know the adage: "Premature optimization is the root of all evil." (-Donald Knuth). **Free by habit, decide not to by choice.** – CodeMouse92 Apr 12 '16 at 22:41
  • Unfortunately, many college/uni courses are taught by people who have never actually delivered anything that works:( – Martin James Apr 13 '16 at 11:51
  • 2
    Unnecessary and unwarranted explicit freeing is premature stoptimization. – Martin James Apr 13 '16 at 11:52
12

It depends on the OS. Best practice I'd say you should explicitly free it. It also makes using tools like valgrind a PITA if you have memory not freed all over the place and I cannot tell what's good and bad etc.

If on an OS that explicitly frees memory you still have the problem of other resources. As your app starts to grow and pull in third party libraries you can get resource leaks. Imagine I've written a library that asks that you call close on a handler. This handler happens to be backed by temporary files that doesn't get deleted unless you call close. Or I've detached processes that are running in the background that I'm managing using signals or some other resource that you're unaware of.

Harry
  • 11,298
  • 1
  • 29
  • 43
  • 5
    Which systems cannot free memory after program termination? – fuz Apr 12 '16 at 21:22
  • 1
    Have a look in the comments here... http://stackoverflow.com/questions/2975831/is-leaked-memory-freed-up-when-the-program-exits and here. http://stackoverflow.com/questions/6727383/dynamically-allocated-memory-after-program-termination – Harry Apr 12 '16 at 21:26
  • 5
    The way to handle temp files is to delete them on runup, not on shutdown. Power can fail at any time, and apps that rely absoultely on a shutdown procedure will be in trouble. – Martin James Apr 12 '16 at 21:28
  • 1
    @Harry If you are programming for such a system, you know this and don't ask this kind of question on Stack Overflow. – fuz Apr 12 '16 at 21:30
  • 2
    @MartinJames do both? Leave no mess behind, boyscott principle and all – Sled Jan 30 '19 at 22:38
0

I had completely opposite scenario: segfaulting destructors of static objects from third-party library. Just because of explicitly freeing memory pools before exit. I believe, it is better to be reasonable and to concentrate on program structure.

Yuriy Vasylenko
  • 3,031
  • 25
  • 25