Does this program have a memory leak?


The program itself has a leak. Whether the operating system cleans this up or not is a different matter. I suppose it's better to ask 'could this program potentially cause a problem on any system?' and the answer is absolutely yes.

The C standard nowhere says that memory allocated with malloc will be freed at program termination, either normal or abnormal. Compare that to open files, which are guaranteed to be closed for you by the C implementation if the program terminates normally.

Simple answer is yes. The OS is doing the tidying up for you


For the benefit of gg.kaspersky.

When the program gets to the end you should have tidied up the heap. It says that you have considered all the allocations and provided the release of those resources (this can be said to be true for open files or other OS resources).

Is this complicated enough for you?

BTW - It is good manners when visiting a home (OS) you leave it in the same state as you arrived.

Your question is incomplete... and as such the best answer you can get is "it depends".

From a program scope, yes, you have a memory leak. That much should be obvious. From a system scope the answer is it depends on which operating system you're running on.

In general if you're programming on a main stream device (Win7/MacOSX/Linux desktop/laptop computer, iOS/Android device, etc) you're pretty safe. I can't think of any main stream modern operating systems which would not be able to clean up after you.

However, if you're working on some older or embedded systems, you will leak memory here. I've seen memory leaks on a uCLinux platform (an OS specifically designed for hardware which does not have an MMU[Memory Management Unit]).

Dynamic memory is generally considered dangerous, which is why it's not legal to use it on some RTOSs. If you know the scope of deployment of your application throughout the lifetime of its use, you're fine to code like this... but the odds are you don't, and you shouldn't make assumptions about what the OS will do. Always clean up your own mess.

I wouldn't consider that a memory leak. The memory is still accessible through a variable that is still in scope when you exit.

Freeing all memory you allocated at the end of a program is just being unnecessarily pedantic and makes you spend time doing something that the operating system will do for you much more efficiently.

Edit (technical details):

With some implementations of malloc doing unnecessary freeing of memory at the end of a program can be horribly inefficient. All malloc implementations that keep their accounting information inline (through boundary tags or a similar mechanism) will touch most, if not all, pages that you have allocated. Normally this isn't a problem besides dirtying cache lines and TLB entries that are being thrown away, but couple this with a program that used enough memory to start using swap and you end up swapping in a lot of memory just to free it. The operating system can do this much more efficiently when you exit (by just marking the swap slots as free).

If you have a malloc implementation that returns memory to the operating system, freeing the memory will cause the operating system to unmap the memory which in turn requires expensive TLB operations if you're on a multiprocessor system. On exit the invalidation can be done much more efficiently (either by doing a full TLB flush or invalidating the TLB tag).


 ? Is it really important to free allocated memory if the program's just about to exit?
 ? Is necessary to do a free(string) before end a program?
 ? Memory leak in malloc
 ? Is there a reason to call delete in C++ when a program is exiting anyway?
 ? Does calling free or delete ever release memory back to the "system"
 ? When a program terminates what happens to the memory allocated using malloc that is not free'ed?
 ? Segmentation fault when malloc/free appear in loop in C
 ? Some memory seems to be left allocated after malloc() and free()
 ? Intricacies of malloc and free
 ? Puzzling behavior, malloc and free(), with libuv