What REALLY happens when you don t free after malloc

Question

This has been something that has bothered me for ages now   We are all taught in school  at least  I was  that you MUST free every pointer that is allocated   I m a bit curious  though  about the real cost of not freeing memory   In some obvious cases  like when malloc is called inside a loop or part of a thread execution  it s very important to free so there are no memory leaks   But consider the following two examples   First  if I have code that s something like this   int main         char  a   malloc 1024          Do some arbitrary stuff with  a   no alloc functions         return 0      What s the real result here   My thinking is that the process dies and then the heap space is gone anyway so there s no harm in missing the call to free  however  I do recognize the importance of having it anyway for closure  maintainability  and good practice    Am I right in this thinking   Second  let s say I have a program that acts a bit like a shell   Users can declare variables like aaa   123 and those are stored in some dynamic data structure for later use   Clearly  it seems obvious that you d use some solution that will calls some  alloc function  hashmap  linked list  something like that    For this kind of program  it doesn t make sense to ever free after calling malloc because these variables must be present at all times during the program s execution and there s no good way  that I can see  to implement this with statically allocated space   Is it bad design to have a bunch of memory that s allocated but only freed as part of the process ending   If so  what s the alternative

User · Answer

I typically free every allocated block once I'm sure that I'm done with it. Today, my program's entry point might be main(int argc, char *argv[]) , but tomorrow it might be foo_entry_point(char **args, struct foo *f) and typed as a function pointer.

So, if that happens, I now have a leak.

Regarding your second question, if my program took input like a=5, I would allocate space for a, or re-allocate the same space on a subsequent a="foo". This would remain allocated until:

The user typed 'unset a'
My cleanup function was entered, either servicing a signal or the user typed 'quit'

I can not think of any modern OS that does not reclaim memory after a process exits. Then again, free() is cheap, why not clean up? As others have said, tools like valgrind are great for spotting leaks that you really do need to worry about. Even though the blocks you example would be labeled as 'still reachable' , its just extra noise in the output when you're trying to ensure you have no leaks.

Another myth is "If its in main(), I don't have to free it", this is incorrect. Consider the following:

char *t;

for (i=0; i < 255; i++) {
    t = strdup(foo->name);
    let_strtok_eat_away_at(t);
}

If that came prior to forking / daemonizing (and in theory running forever), your program has just leaked an undetermined size of t 255 times.

A good, well written program should always clean up after itself. Free all memory, flush all files, close all descriptors, unlink all temporary files, etc. This cleanup function should be reached upon normal termination, or upon receiving various kinds of fatal signals, unless you want to leave some files laying around so you can detect a crash and resume.

Really, be kind to the poor soul who has to maintain your stuff when you move on to other things .. hand it to them 'valgrind clean' :)

User · Answer

I think that your two examples are actually only one  the free   should occur only at the end of the process  which as you point out is useless since the process is terminating   In you second example though  the only difference is that you allow an undefined number of malloc    which could lead to running out of memory  The only way to handle the situation is to check the return code of malloc   and act accordingly

User · Answer

This code will usually work alright  but consider the problem of code reuse   You may have written some code snippet which doesn t free allocated memory  it is run in such a way that memory is then automatically reclaimed  Seems allright   Then someone else copies your snippet into his project in such a way that it is executed one thousand times per second  That person now has a huge memory leak in his program  Not very good in general  usually fatal for a server application   Code reuse is typical in enterprises  Usually the company owns all the code its employees produce and every department may reuse whatever the company owns  So by writing such  innocently-looking  code you cause potential headache to other people  This may get you fired

User · Answer

What s the real result here    Your program leaked the memory  Depending on your OS  it may have been recovered   Most modern desktop operating systems do recover leaked memory at process termination  making it sadly common to ignore the problem  as can be seen by many other answers here    But you are relying on a safety feature you should not rely upon  and your program  or function  might run on a system where this behaviour does result in a  hard  memory leak  next time   You might be running in kernel mode  or on vintage   embedded operating systems which do not employ memory protection as a tradeoff   MMUs take up die space  memory protection costs additional CPU cycles  and it is not too much to ask from a programmer to clean up after himself    You can use and re-use memory any way you like  but make sure you deallocated all resources before exiting

User · Answer

There s no real danger in not freeing your variables  but if you assign a pointer to a block of memory to a different block of memory without freeing the first block  the first block is no longer accessible but still takes up space  This is what s called a memory leak  and if you do this with regularity then your process will start to consume more and more memory  taking away system resources from other processes   If the process is short-lived you can often get away with doing this as all allocated memory is reclaimed by the operating system when the process completes  but I would advise getting in the habit of freeing all memory you have no further use for

User · Answer

I completely disagree with everyone who says OP is correct or there is no harm  Everyone is talking about a modern and or legacy OS s  But what if I m in an environment where I simply have no OS  Where there isn t anything  Imagine now you are using thread styled interrupts and allocate memory  In the C standard ISO IEC 9899 is the lifetime of memory stated as   7 20 3 Memory management functions 1 The order and contiguity of storage allocated by successive calls to the calloc  malloc  and realloc functions is unspecified  The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object or an array of such objects in the space allocated  until the space is explicitly deallocated   The lifetime of an allocated object extends from the allocation until the deallocation        So it has not to be given that the environment is doing the freeing job for you  Otherwise it would be added to the last sentence   quot Or until the program terminates  quot  So in other words  Not freeing memory is not just bad practice  It produces non portable and not C conform code  Which can at least be seen as  correct  if the following         is supported by environment   But in cases where you have no OS at all  no one is doing the job for you  I know generally you don t allocate and reallocate memory on embedded systems  but there are cases where you may want to   So speaking in general plain C  as which the OP is tagged   this is simply producing erroneous and non portable code

User · Answer

What about future proofing and code reuse       If you don t write the code to free the objects  then you are limiting the code to only being safe to use when you can depend on the memory being free d by the process being closed     i e  small one-time use projects or  throw-away  1  projects     where you know when the process will end   If you do write the code that free  s all your dynamically allocated memory  then you are future proofing the code and letting others use it in a larger project      1  regarding  throw-away  projects  Code used in  Throw-away  projects has a way of not being thrown away  Next thing you know ten years have passed and your  throw-away  code is still being used    I heard a story about some guy who wrote some code just for fun to make his hardware work better  He said  just a hobby  won t be big and professional   Years later lots of people are using his  hobby  code

User · Answer

Yes you are right  your example doesn t do any harm  at least not on most modern operating systems   All the memory allocated by your process will be recovered by the operating system once the process exits    Source  Allocation and GC Myths  PostScript alert       Allocation Myth 4  Non-garbage-collected programs   should always deallocate all memory   they allocate        The Truth  Omitted   deallocations in frequently executed   code cause growing leaks  They are   rarely acceptable  but Programs that   retain most allocated memory until   program exit often perform better   without any intervening deallocation    Malloc is much easier to implement if   there is no free       In most cases  deallocating memory   just before program exit is pointless    The OS will reclaim it anyway  Free   will touch and page in the dead   objects  the OS won t       Consequence  Be careful with  leak   detectors  that count allocations    Some  leaks  are good    That said  you should really try to avoid all memory leaks    Second question  your design is ok  If you need to store something until your application exits then its ok to do this with dynamic memory allocation  If you don t know the required size upfront  you can t use statically allocated memory

User · Answer

There s actually a section in the OSTEP online textbook for an undergraduate course in operating systems which discusses exactly your question   The relevant section is  Forgetting To Free Memory  in the Memory API chapter on page 6 which gives the following explanation      In some cases  it may seem like not calling free   is reasonable  For   example  your program is short-lived  and will soon exit  in this case    when the process dies  the OS will clean up all of its allocated pages and   thus no memory leak will take place per se  While this certainly    works       see the aside on page 7   it is probably a bad habit to develop  so be wary   of choosing such a strategy   This excerpt is in the context of introducing the concept of virtual memory  Basically at this point in the book  the authors explain that one of the goals of an operating system is to  virtualize memory   that is  to let every program believe that it has access to a very large memory address space   Behind the scenes  the operating system will translate  virtual addresses  the user sees to actual addresses pointing to physical memory   However  sharing resources such as physical memory requires the operating system to keep track of what processes are using it  So if a process terminates  then it is within the capabilities and the design goals of the operating system to reclaim the process s memory so that it can redistribute and share the memory with other processes     EDIT  The aside mentioned in the excerpt is copied below      ASIDE  WHY NO MEMORY IS LEAKED ONCE YOUR PROCESS EXITS      When you write a short-lived program  you might allocate some space   using malloc    The program runs and is about to complete  is there   need to call free   a bunch of times just before exiting  While it seems   wrong not to  no memory will be  lost  in any real sense  The reason is   simple  there are really two levels of memory management in the system    The first level of memory management is performed by the OS  which   hands out memory to processes when they run  and takes it back when   processes exit  or otherwise die   The second level of management   is within each process  for example within the heap when you call   malloc   and free    Even if you fail to call free    and thus leak   memory in the heap   the operating system will reclaim all the memory of   the process  including those pages for code  stack  and  as relevant here    heap  when the program is finished running  No matter what the state   of your heap in your address space  the OS takes back all of those pages   when the process dies  thus ensuring that no memory is lost despite the   fact that you didn   t free it       Thus  for short-lived programs  leaking memory often does not cause any   operational problems  though it may be considered poor form   When   you write a long-running server  such as a web server or database management   system  which never exit   leaked memory is a much bigger issue    and will eventually lead to a crash when the application runs out of   memory  And of course  leaking memory is an even larger issue inside   one particular program  the operating system itself  Showing us once   again  those who write the kernel code have the toughest job of all              from Page 7 of Memory API chapter of          Operating Systems  Three Easy Pieces     Remzi H  Arpaci-Dusseau and Andrea C  Arpaci-Dusseau      Arpaci-Dusseau Books      March  2015  Version 0 90

User · Answer

If a program forgets to free a few Megabytes before it exits the operating system will free them  But if your program runs for weeks at a time and a loop inside the program forgets to free a few bytes in each iteration you will have a mighty memory leak that will eat up all the available memory in your computer unless you reboot it on a regular basis    even small memory leaks might be bad if the program is used for a seriously big task even if it originally wasn t designed for one

User · Answer

If you re developing an application from scratch  you can make some educated choices about when to call free  Your example program is fine  it allocates memory  maybe you have it work for a few seconds  and then closes  freeing all the resources it claimed   If you re writing anything else  though -- a server long-running application  or a library to be used by someone else  you should expect to call free on everything you malloc   Ignoring the pragmatic side for a second  it s much safer to follow the stricter approach  and force yourself to free everything you malloc  If you re not in the habit of watching for memory leaks whenever you code  you could easily spring a few leaks  So in other words  yes -- you can get away without it  please be careful  though

User · Answer

You are correct  no harm is done and it s faster to just exit  There are various reasons for this    All desktop and server environments simply release the entire memory space on exit    They are unaware of program-internal data structures such as heaps  Almost all free   implementations do not ever return memory to the operating system anyway  More importantly  it s a waste of time when done right before exit    At exit  memory pages and swap space are simply released  By contrast  a series of free   calls will burn CPU time and can result in disk paging operations  cache misses  and cache evictions    Regarding the possiblility of future code reuse justifing the certainty of pointless ops  that s a consideration but it s arguably not the Agile way  YAGNI

User · Answer

It is completely fine to leave memory unfreed when you exit  malloc   allocates the memory from the memory area called  the heap   and the complete heap of a process is freed when the process exits   That being said  one reason why people still insist that it is good to free everything before exiting is that memory debuggers  e g  valgrind on Linux  detect the unfreed blocks as memory leaks  and if you have also  real  memory leaks  it becomes more difficult to spot them if you also get  fake  results at the end

User · Answer

You are correct  memory is automatically freed when the process exits   Some people strive not to do extensive cleanup when the process is terminated  since it will all be relinquished to the operating system   However  while your program is running you should free unused memory   If you don t  you may eventually run out or cause excessive paging if your working set gets too big

User · Answer

If you re using the memory you ve allocated  then you re not doing anything wrong  It becomes a problem when you write functions  other than main  that allocate memory without freeing it  and without making it available to the rest of your program   Then your program continues running with that memory allocated to it  but no way of using it  Your program and other running programs are deprived of that memory   Edit  It s not 100  accurate to say that other running programs are deprived of that memory  The operating system can always let them use it at the expense of swapping your program out to virtual memory   lt  handwaving gt    The point is  though  that if your program frees memory that it isn t using then a virtual memory swap is less likely to be necessary

User · Answer

You are absolutely correct in that respect  In small trivial programs where a variable must exist until the death of the program  there is no real benefit to deallocating the memory   In fact  I had once been involved in a project where each execution of the program was very complex but relatively short-lived  and the decision was to just keep memory allocated and not destabilize the project by making mistakes deallocating it    That being said  in most programs this is not really an option  or it can lead you to run out of memory

User · Answer

It depends on the scope of the project that you re working on  In the context of your question  and I mean just your question  then it doesn t matter  For a further explanation  optional   some scenarios I have noticed from this whole discussion is as follow   1  - If you re working in an embedded environment where you cannot rely on the main OS  to reclaim the memory for you  then you should free them since memory leaks can really crash the program if done unnoticed   2  - If you re working on a personal project where you won t disclose it to anyone else  then you can skip it  assuming you re using it on the main OS   or include it for  quot best practices quot  sake   3  - If you re working on a project and plan to have it open source  then you need to do more research into your audience and figure out if freeing the memory would be the better choice   4  - If you have a large library and your audience consisted of only the main OS   then you don t need to free it as their OS  will help them to do so  In the meantime  by not freeing  your libraries program may help to make the overall performance snappier since the program does not have to close every data structure  prolonging the shutdown time  imagine a very slow excruciating wait to shut down your computer before leaving the house     I can go on and on specifying which course to take  but it ultimately depends on what you want to achieve with your program  Freeing memory is considered good practice in some cases and not so much in some so it ultimately depends on the specific situation you re in and asking the right questions at the right time  Good luck

User · Answer

Just about every modern operating system will recover all the allocated memory space after a program exits   The only exception I can think of might be something like Palm OS where the program s static storage and runtime memory are pretty much the same thing  so not freeing might cause the program to take up more storage    I m only speculating here    So generally  there s no harm in it  except the runtime cost of having more storage than you need   Certainly in the example you give  you want to keep the memory for a variable that might be used until it s cleared   However  it s considered good style to free memory as soon as you don t need it any more  and to free anything you still have around on program exit   It s more of an exercise in knowing what memory you re using  and thinking about whether you still need it   If you don t keep track  you might have memory leaks   On the other hand  the similar admonition to close your files on exit has a much more concrete result - if you don t  the data you wrote to them might not get flushed  or if they re a temp file  they might not get deleted when you re done   Also  database handles should have their transactions committed and then closed when you re done with them   Similarly  if you re using an object oriented language like C   or Objective C  not freeing an object when you re done with it will mean the destructor will never get called  and any resources the class is responsible might not get cleaned up

[c] What REALLY happens when you don't free after malloc?

Examples related to c

Examples related to malloc

Examples related to free