What are the long term consequences of memory leaks?

Question

Suppose I had a program like this:

int main(void)
{
    int* arr = new int[x];
    //processing; neglect to call delete[]
    return 0;
}

In a trivial example such as this, I assume there is little actual harm in neglecting to free the memory allocated for arr, since it should be released by the OS when the program is finished running. For any non-trivial program, however, this is considered to be bad practice and will lead to memory leaks.

My question is, what are the consequences of memory leaks in a non-trivial program? I realize that memory leaks are bad practice, but I do not understand why they are bad and what trouble they cause.

Answer 1

A memory leak can diminish the performance of the computer by reducing the amount of available memory. Eventually, in the worst case, too much of the available memory may become allocated and all or part of the system or device stops working correctly, the application fails, or the system slows down unacceptably due to thrashing.

Memory leaks may not be serious or even detectable by normal means. In modern operating systems, normal memory used by an application is released when the application terminates. This means that a memory leak in a program that only runs for a short time may not be noticed and is rarely serious.

Much more serious leaks include those:

• where the program runs for an extended time and consumes additional memory over time, such as background tasks on servers, but especially in embedded devices which may be left running for many years
• where new memory is allocated frequently for one-time tasks, such as when rendering the frames of a computer game or animated video
• where the program can request memory — such as shared memory — that is not released, even when the program terminates
• where memory is very limited, such as in an embedded system or portable device
• where the leak occurs within the operating system or memory manager
• when a system device driver causes the leak
• running on an operating system that does not automatically release memory on program termination. Often on such machines if memory is lost, it can only be reclaimed by a reboot, an example of such a system being AmigaOS.

Check out here for more info.

Answer 2

There is an underlying assumption to your question:

The role of delete and delete[] is solely to release memory.

... and it is erroneous.

For better or worse, delete and delete[] have a dual role:

1. Run destructors
2. Free memory (by calling the right overload of operator delete)

With the corrected assumption, we can now ask the corrected question:

What is the risk in not calling delete/delete[] to end the lifetime of dynamically allocated variables ?

As mentioned, an obvious risk is leaking memory (and ultimately crashing). However this is the least of your worries. The much bigger risk is undefined behavior, which means that:

• compiler may inadvertently not produce executable code that behaves as expected: Garbage in, Garbage out.
• in pragmatic terms, the most likely output is that destructors are not run...

The latter is extremely worrisome:

• Mutexes: Forget to release a lock and you get a deadlock...
• File Descriptors: Some platforms (such as FreeBSD I believe) have a notoriously low default limit on the number of file descriptors a process may open; fail to close your file descriptors and you will not be able to open any new file or socket!
• Sockets: on top of being a file descriptor, there is a limited range of ports associated to an IP (which with the latest version of Linux is no longer global, yeah!). The absolute maximum is 65,536 (u16...) but the ephemeral port range is usually much smaller (half of it). If you forget to release connections in a timely fashion you can easily end up in a situation where even though you have plenty of bandwidth available, your server stops accepting new connections because there is no ephemeral port available.
• ...

The problem with the attitude of well, I got enough memory anyway is that memory is probably the least of your worries simply because memory is probably the least scarce resource you manipulate.

Of course you could say: Okay, I'll concentrate on other resources leak, but tools nowadays report them as memory leaks (and it's sufficient) so isolating that leak among hundreds/thousands is like seeking a needle in a haystack...

Note: did I mention that you can still run out of memory ? Whether on lower-end machines/systems or on a restricted processes/virtual-machines memory can be quite tight for the task at hand.

Note: if you find yourself calling delete, you are doing it wrong. Learn to use the Standard Library std::unique_ptr and its containers std::vector. In C++, automatic memory management is easy, the real challenge is to avoid dangling pointers...