I know that if I don't free allocated memory with delete/free I'd end up with memory leaks. My question is: if my program gets terminated, does the operating system free the memory for me even if I didn't?
-
its seems as duplicate question – Jeegar Patel Feb 06 '13 at 11:43
5 Answers
In short, yes.
All storage mapped into a process' address space will be returned to the operating system when that process terminates, even if you did not explicitly free it.

- 258,201
- 41
- 486
- 479
-
This is true, but it is important to take note of the point raised in juanchopanza's answer. – Viktor Dahl Feb 06 '13 at 11:27
-
@Viktor, the operating system also releases resources held by the process when it terminates (such as file handles). Unless you're working with shared memory handles, this won't be an issue. – Frédéric Hamidi Feb 06 '13 at 11:28
-
1@ViktorDahl despite what I said in my answer, **if** you do things properly in C++ you never have to call `delete` anyway, so this should be a non-issue. That is a big if though... – juanchopanza Feb 06 '13 at 11:35
-
@David, I meant the physical memory that was mapped into the process' address space will be available again to the operating system (which is then free to do something else with it). Can you clarify what you mean by physical memory already being returned to the OS? – Frédéric Hamidi Feb 06 '13 at 11:41
-
@David, on second thought and from your answer, I think that's a terminology issue. Would my answer have been less confusing had I said "storage" instead of "memory"? – Frédéric Hamidi Feb 06 '13 at 11:45
-
@David, okay, so "storage" is still ambiguous but "backing store" would be fine? Because I was under the (possibly wrong) impression that the latter was a subset of the former. – Frédéric Hamidi Feb 06 '13 at 11:58
In C++, delete will result in the destructor of the object being called. This destructor may take care of things other than releasing memory. It may close files, reduce reference counts, etc. So there is no telling what may go wrong if you neglect to delete a dynamically allocated object.

- 223,364
- 34
- 402
- 480
-
But besides some rare cases the OS will free such resources (like open file handles etc.) as well when a program is terminated. – πάντα ῥεῖ Feb 06 '13 at 11:27
-
@g-makulik but it might mean keeping 1000s of handles open instead of one or two at any given time... – juanchopanza Feb 06 '13 at 11:33
Whether the memory leaks or not depends on the Operating system. In case of most operating systems once the process in which your program runs exits the OS simply reclaims back the memory it allocated to the process.
There is another important aspect to it. new
results in calling of the class constructor and delete
results in call to an destructor. So if you called new
and never called delete
then in addition to the so called memory leak which may/may not exist after the program exit there is an additional condition that if the destructor of the particular class invokes some code which has side effects then it results in Undefined Behavior.
So the answer is it depends, You may possibly have:
- A memory leak(depending on the OS behavior)
- An undefined behavior(depending on whether code in destructor has side effects)
C++11 Standard 3.8 Object lifetime:
Para 4:
A program may end the lifetime of any object by reusing the storage which the object occupies or by explicitly calling the destructor for an object of a class type with a non-trivial destructor. For an object of a class type with a non-trivial destructor, the program is not required to call the destructor explicitly before the storage which the object occupies is reused or released; however, if there is no explicit call to the destructor or if a delete-expression (5.3.5) is not used to release the storage, the destructor shall not be implicitly called and any program that depends on the side effects produced by the destructor has undefined behavior.
If you wouldn't call delete
- no destructors will be called. If any destructor closes the file, writes something to database, etc., then these actions wouldn't be done

- 4,988
- 25
- 42
Your question seems to be based on a naive understanding of how memory works that just doesn't correspond to what a modern operating system does. The term "memory" is confusingly ambiguous, and you really should think of physical memory (RAM) and virtual memory (address space) separately.
When you call malloc
, you reserve address space in your process. If the operating system thinks it's wise to do so, it backs that address space with physical RAM. If the OS wants to use that RAM for something else, it simply does. You can't stop it. So you don't have to worry about RAM. The operating system is smart enough to always put RAM to its best use even if it's not specifically freed by a process.
Virtual memory, mere address space, is not scarce. And your address space ceases to exist as soon as your process is terminated. So there is nothing to return.
As soon as memory is unreachable, the operating system has no choice but to make it free.

- 179,497
- 17
- 214
- 278
-
2`malloc` is generally required to do more than just reserve address space; the system must do something to ensure that accesses to that address space do not fail, which generally means either mapping it immediately, or reserving the pages to be certain to be able to map it later. If the OS doesn't do at least this, it's horribly broken, and should be avoided for any serious work. – James Kanze Feb 06 '13 at 11:43
-
Even though the OS can page physically backed memory out whenever it needs to, it (generally) still places some limit to the maximum amount of memory that can be swapped out... thus it is _not_ prudent to hang on to large amounts of allocation that you know you don't need anymore. – mah Feb 06 '13 at 11:48
-
@JamesKanze: Generally, the OS will have some measure of how much backing store (RAM + swap) it has. The `malloc` function will reserve against this. If a system is properly configured, backing store should not be a scarce resource unless it's a small/embedded system. On such systems, additional effort is taken to reduce waste of backing store. (And by the way, by your definition, most modern operating systems are broken. They can't actually ensure that. If Linux could, it wouldn't need an OOM killer.) – David Schwartz Feb 06 '13 at 11:55