Home/ Questions/Q 1012931
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T10:01:15+00:00

The general rule, only objects allocated in the free store can cause memory leaks.

  • 0

The general rule, only objects allocated in the free store can cause memory leaks.
But objects created in the stack doesn’t.

Here is my doubt,

int main()
    {
      myclass x;

      ...

      throw;

      ...
    }

If throw is not handled, it calls, terminate(), which in turn calls abort() and crashes the application. At this time, the objects in the stack are not destoryed (The destructor is not invoked).

My understanding is “When the application terminates (either by abort or by normal exit), it frees all the memory that was allocated for the application”. Thus this cannot be considered as memory leak.

Am I correct?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    In a hosted environment (e.g. your typical Unix / Windows / Mac OS X, even DOS, machine) when the application terminates all the memory it occupied is automatically reclaimed by the operating system. Therefore, it doesn’t make sense to worry about such memory leaks.

    In some cases, before an application terminates, you may want to release all the dynamic memory you allocated in order to detect potential memory leaks through a leak detector, like valgrind. However, even in such a case, the example you describe wouldn’t be considered a memory leak.

    In general, failing to call a destructor is not the same as causing a memory leak. Memory leaks stem from memory allocated on the heap (with new or malloc or container allocators). Memory allocated on the stack is automatically reclaimed when the stack is unwound. However, if an object holds some other resource (say a file or a window handle), failing to call its destructor will call a resource leak, which can also be a problem. Again, modern OSs will reclaim their resources when an application terminates.

    • 0