Memory Leak and Operating System

I understand that each process has its own address space allocated by the Operating System. So when the program terminates, that whole address space is marked as invalid (or is free to be reused again). Now if the said process is leaking memory, will it make any difference after the program is terminated ?

That is to say, 开发者_运维技巧if my program is terminated after sometime or is run at short intervals with continuous start-finish mechanism, will leaking memory make much difference ? (i am assuming the leak is not large enough to cause thrashing on an average system)

I know leaks are bad - but my question stems from the point that suppose an object is being used in the final routine of the code - will NOT FIXING the leak make any difference as the process is going to be terminated after this anyway ?

Thanks in Advance :)

This is a very OS-dependent question.

On a modern multiprocessing OS that uses Virtual Memory (eg: Windows 7, Linux), it is true that all (OK, not all, but let's not be nit-picky here) resources are process-specific and will be released back to the system when the process terminates.

So does it matter if your program "leaks memory"? Well, that depends on how it does it.

If you allocate a bunch of resources at startup, no it does not really matter if you manually free them at shutdown or just let the OS do it. I'll admit to being a lazy programmer who likes to let the OS handle such things.

However, if you allocate resources in a loop or on demand at runtime for some reason, and don't bother to manage them in some way, then theoretically if you let your program run long enough it will continually "leak" resources until the point comes that there aren't any more left to allocate. This is a Bad Thing. Don't do it.

Now there are a lot of platforms that do not behave this way. If you ever end up doing embedded work, you are quite likely to end up on a platform where you have to manage all of your own resources (manually free memory, close file handles, etc.)

In modern operating systems with separated kernel and user space and a memory manager, in which every user process only sees virtual memory (as you said), it is generally indeed not possible for any given user process to hurt the OS (excluding of course things like privileged users deliberately messing with the system memory). That's the entire idea of multi-process multi-tasking operating systems: Having many simultaneous processes managed by the OS, and not having to rely on the processes being cooperative.

(That said, if memory leaks are due to invalid access bugs, you are still susceptible to code injection, which can be further aggravated by privilege elevation vulnerabilities in other parts of your system, so the insulation of a process only goes so far.)

If you're just grabbing some more heap than you should really need it will be reclaimed when the process exits.

I'm not clear how you know that you're leaking memory in this situation, but assuming that you are indeed doing so then you should still fix it. It's a time-bomb in your code.

Two examples of why:

1. The code you have may be reused somewhere else, either by cut-and-paste or by refactoring.

2. You may have scalability issues:

   for (some list of things ) do some work that leaks 100 bytes

right now you iterate 10 times, leak 1,000 bytes, terminate, no big deal. In the future you interate 10,000 times and essential shut-down work fails due to out-of-memory ...