and the OS does that because it is an interrupt?
whereas if the program completes (and I don't free memory), the OS won't free it for me? thus leading to a memory leak?
PS. actually thinking about it (should have thought first!), the memory leak occurs while the program is running...
thanks
That is typically when memory leaks occur... unless you are running Windows. In which case memory leaks are part of the operational process. In all seriousness though, you should be aware that typically the OS will just return all memory that a process was using back to the system once execution of that process has ceased. So memory leaks are usually irrelevant once the program has closed. The exceptions to the rules are OS specific and not worth mentioning at this point.
Yes, the problem with memory leaks in general is that the APPLICATION, if it runs for long enough, will use up all memory (or much more than it should), which will cause problems where the system runs slowly, and perhaps also cause the application to crash if it doesn't handle running out of memory well.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
ok, so just to clarify (so I never need ask again!).
if the program is interrupted, the OS will free up any memory that has been allocated.
if the program exits (finishes, crashes), the OS will free up any memory that has been allocated.
if the program runs for 100 days and each 24 hours you malloc some memory, but don't free that memory once you've finished with it, a memory leak is the result and your memory runs out and the system grinds to a halt.
by 'free up' I mean is marked as available to other processes.
I am on unix only, had my fill of MS. Incidentally, I used to do MS support on Exchange. I have troubleshooted many a memory leak in the MTA (emsmta.exe). Good to understand the causes, etc.
thanks for your patience, explanations...
I hate to use absolutes since I have made programs that do cause problems that the OS was completely unable to acknowledge or cope with on its own (which is good, since it helps you know how to reproduce/avoid these situations).
A good general rule of thumb is that anything that application does, is undone as soon as the program is interrupted. File handles are eliminated. Memory handles are returned back to the OS. Sockets are invalidated. In theory the OS returns to the state it would be in had your program not run at all. In practice that isn't always the case. But that is a whole nother thread.
dougieb, essentially, yes.
The OS manages your process, and its going away no matter how it went. By its own volition or by force.
I have a quibble with your phrase "...but don't free that memory once you've finished with it, a memory leak is the result and ..."
A memory leak is what is happening slowly, a dribble at a time. It's not an instantaneous end result. Hence they may go undetected in many programs. Even commercial ones. They terminate normally before all memory is exhausted. Lucky for them. Saving face of their creators. But not to their credit.
It would be nice if the operating system told you "hey by the way, that recent program that just finished? it left crappola all over the place, had open files, allocated crud, and was ugly". It could avert unexpected headaches down the road during Christmas season when transactions are at their peak, if you're in such an environment. The worst time for things to blow up.
To some degree, that's true.Originally Posted by nonoob
There are methods for findings leaks and so, thankfully. And there are lots of "verifier" programs out there that make sure you don't leak memory or handles, etc.
Oh and, just because the OS will clean everything up for you doesn't mean it's good practice to ignore closing handles and freeing memory. Some tend to skip doing that when the application is closing down and having the OS clean it up.
Many consider it bad practice.
that's great guys, makes sense.
thanks,
