Is a processes memory reclaimed when it terminates?

user_7571171 0
Viewed 1624

In an application of mine I basically allocate memory in C++ and enqueue it for deallocation in C#. This deallocation runs in the background and is non-deterministic, so in very rare cases it can theoretically happen that the application is exited before all the unmanaged memory is deallocated.

If that is the case, the behaviour is (roughly and very stripped down) the same as if my program was

int main()
{
   Foo* = new Foo();
   return 0;
}

my questions now are

  • Is all the memory a program allocates, but not deallocates automatically reclaimed when the program exits or is it a memory leak that stays until I reboot?
  • If it is automatically reclaimed, what mechanism is responsible for that?

EDIT: This is about Windows only, as some mentioned that this is OS-dependent.

EDIT 2: I am not talking about simply ignoring all memory leaks in my application, but about whether I need to make sure that all memory is properly deallocated right before the application exits.

EDIT 3: This is not about open file handles, destructors and side effects or anything, this is about memory that will be non-deterministically deallocated and very rare cases where the memory is not freed before termination.

ram memory-leaks memory memory-management c++
5 Answers

Is all the memory a program allocates, but not deallocates automatically reclaimed when the program exits or is it a memory leak that stays until I reboot?

The memory is reclaimed automatically by the operating system when the process terminates.

If it is automatically reclaimed, what mechanism is responsible for that?

Memory manager of C++, the one behind new, delete, malloc, etc. gets its memory in relatively large blocks from the operating system, and is responsible for managing memory chunks of much smaller granularity. Operating system tracks all memory that has been allocated to a process, and reclaims it when the process terminates.

user_3358580

If you care only about memory, you might not need to call delete because the operating system will destroy your entire virtual address space at process termination. Consider reading Operating Systems: Three Easy Pieces (freely downloadable) to understand more about OSes.

But you want to avoid memory leaks, so you'll better clean up properly. On some operating systems, you have tools like valgrind to help detect such leaks (so you don't want them to give spurious warnings).

Read also about RAII. In real life, the constructor (or other methods) of Foo (or indirect data used by it) could consume other resources (database connections, opened files, windows on your screen, daemon processes, remote connections to external services or web servers, robotic arms, etc...) and you want them to be disposed of properly.

Consider using smart pointers.

Liveness of a data structure is a whole program property. I recommend reading the GC handbook, at least to understand the concepts and terminology of garbage collection (which can be viewed as a way to manage resources, and not only raw memory).

(In practice, it depends a lot: if you are coding a million-lines of code program with hundreds of other programmers, you need to be more careful than if you are coding a tiny single-source file program alone; if you code a neural surgery robot it is not the same as a desktop application, etc.... so YMMV)

user_8411080

Unless you are developing low level you work under an operating system. This operating system manages the real memoy providing your application with an virtual memory mapped to the real one.

After your application is shut down (it's process terminated) the operating system removes the virtual memory mapping freeeing all memory ressources of that process.

user_88748170

The answer is that Windows should clean up the memory after you, if it doesn't do so it should be consider as a bug in the operating system. This is also true for Linux, and any other system that let you prematurely kill a process.

The reason for this, and if I understand correctly is also the situation you describe is more similar to the following:

int main()
{
   Foo* foo = new Foo();
   // The process is being brutally kill here. (kill -9 or Windows equivalent)
   delete foo;
   return 0;
}

So even as you done everything as you should, and cleanup after yourself properly, due to the operating system option to prematurely kill your process, it cause a memory leak.

Finally, an important clarification, this does not mean you can just ignore the topic all together, you should do the best effort to clean after yourself, and don't count on other system to clean after you.

user_89089310

There are two distinct levels of memory allocation:

  1. Memory allocation from the OS to the process. This requires a syscall (either brk() or mmap()), and is fully implementation defined. You never see this yourself.

  2. Memory allocation from the process to individual data objects. This is what operator new() does.

new returns a pointer to a data object, and is thus primarily concerned with the second level. However, new in itself has no memory that it can allocate to objects, unless it asks the OS for some memory first. Thus, it needs to first perform a first level allocation.

The implementation of new itself lives entirely within your process. So, when your process dies in an unnatural way (killed due to a signal), the new implementation does not get a chance to clean up anything. But that is not necessary, as the OS itself keeps track on the memory that was allocated on the first level. It simply does not trust some random processes to keep track of their allocated memory themselves. Thus, no permanent memory leak occurs.

However, failing to delete objects that were created with new does have consequences:

  • Your process cannot reuse the memory itself. If you repeatedly allocate objects that you fail to free, your new implementation will need to make more and more first level memory allocations, until your OS has no memory left to give to your process.

  • No delete means that the respective destructors were not called. As such, your process may miss some external cleanup. For instance, failing to destruct an object could mean that some temporary files are not removed from the file system, so your process leaks disk space instead of memory. And you don't want that either, do you?

user_24451840
Related