Memory leaking is something we as developers definitely don't want and should fix when then appear.
However, memory leaks are not necessarily a problem in practice. Unless there is a bug or a memory leak in the OS kernel itself, all leaked memory happening in some buggy software will automatically be freed at the program termination. So the severity of memory leak really depends on actual numbers:
- What is the average memory leaking rate, in bytes per second?
- What is the expected program life time, in seconds?
- How much memory is available on the system?
As an example, a small utility leaking 1 kilobyte per second running only during 1 second on a computer with 32 GB will go totally unnoticed unless you profile it. But if this same utility is a permanent daemon on a production server, it becomes a problem: the amount of allocated memory would increase 86 MB per day, and after a year of uptime the daemon would have leaked 31.5 GB, the same amount as the system memory.
But even in the latter case, the system will probably continue to run smoothly because all the leaked memory would likely be swapped to disk as stay there forever, since the leaked memory cannot be accessed anymore when pointer to it is lost.
A well written software without any memory leak could well allocate gigabytes of memory for its need. This is a much higher memory consumption than a completely naive program written by a beginner, leaking the totally of its few kilobytes.
So my conclusion is that it depends. Most of the time memory leaks in user programs are not a problem, though they should be avoided of course. In an OS kernel and in daemon software, they are usually critical.
Appreciate the clarification. I was looking something like this with a bit relevant background information.