When I hear the term memory leak by that I mean a bug in a program that doesn't cause any problems except that it doesn't free memory resource and if it continuously does that it can eat a lot of memory, hurting system performance and in the worst case crash the program (or an other program, if the OS decides to choose to kill that one).

But now in this comments section of this question the upvotes made me think whether that's the whole meaning of the term. I previously always saw used it in that meaning.


So, would you call something a simple memory leak that crashes a program by some other side-effect or causing a dead-lock by not freeing a lock?

Update - Note: unfortunately some admin deleted the comment section there so I cannot refer to that discussion anymore :/

Basically I said that a memory leak is harmless except that it eats up memory (and consequently on the long term in that respect can be harmful, crashing the app/system). They said that's not true, with C++ RAII it can cause serious problems. - Yes, if you don't delete an object with some important code in the destructor that can cause problems, but in my vocabulary that's a major bug and not a memory leak.

  • 1
    Maybe I'm missing something in your question, but I'd just call it a "memory leak". Resource deadlocks aren't something that I'd call related to memory leaks. (Your definition is correct, by the way.)
    – Adam Lear
    Commented Sep 17, 2011 at 1:05
  • If there was some important information in the comments it should have been edited into the question. You would have been given notice of their pending deletion.
    – ChrisF
    Commented Sep 17, 2011 at 15:26

5 Answers 5


The quintessential memory leak would be exactly what you described, the failure to free some memory the process had allocated. The consequences would normally be that the program gradually grows in size while it's running, with possible secondary effects due to that. Subsequent memory allocations might fail or the system might misbehave due to the wasted resources.

However, a problem can be accurately described as a memory leak so long as it does in fact leak memory. It can also do other things that are potentially more serious. For example, if you fail to close a standard I/O stream, that's a memory leak because memory associated with the stream will be leaked. However, it can also run the process out of file descriptors or perhaps cause a subsequent stream open to fail because of a limit on the number of standard I/O streams.

  • 2
    Is there a terminiological distinction between these? Wouldn't you rather call the mentioned ones resource leaks? Commented Sep 17, 2011 at 1:18
  • 3
    It would depend how much information I had at the time. If I knew it was a leak of a stream, then yes. But if I only saw the memory size growing, all I would know at that time was that there was a memory leak. If I was reporting the bug, I'd say "there's a memory leak". Once the cause was located, we would know that the resource leak was causing the memory leak. Commented Sep 17, 2011 at 1:20

It depends. Certainly the program could have crashed because of a memory leak. But I wouldn't call all crashes memory leaks. A memory leak has a very clear definition.

An application crash could be caused many different things.

  • Unhandled Exception
  • Memory Leak
  • Resource Leak
  • Deadlock
  • Other (bug in code)

At the time of the crash one would have to take a crash/memory dump and use something like Windbg to analyze the state of the code at the time of the crash to determine if it was a memory leak, deadlock, bug, etc.

A memory leak is simply not freeing memory after you are finished with it. This can cause a crash if the resource limits are met as you have noted.

A resource leak is not freeing the resource after you are done with it. An example could be opening a database connection and not closing it after you are finished.

Deadlocks are different than leaks, because leaks can go undetected and could be benign if system resources are not consumed. Deadlocks are a condition which do not build up over time.


A related meaning of "memory leak" applies to languages that use garbage collection. There, memory is supposed to be leaked, but if you fail to do so, it's the same problem.

  • 1
    If you don't dereference an object in a garbage collected language (so that the gc knows it's available for collection), it won't necessarily be garbage collected, at which point it's considered a leak. Commented Sep 17, 2011 at 2:17
  • @Matthew: in most properly GC'd languages, you have to pull quite some tricks to avoid releasing references to your objects - in C#, you can do it by failing to unsubscribe from an event, but other than that, I'm not aware of any ways to do this accidentally.
    – tdammers
    Commented Sep 17, 2011 at 14:10
  • hash tables are a good way to "forget" to dereference. Also, modern garbage collectors are so good at sweeping up short lived objects, you can really feel it when stuff hangs around just a little too long.
    – ddyer
    Commented Sep 20, 2011 at 7:18

Memory Leaks happen If you fail to delete dynamically allocated memory. Tracking down memory leaks is one of the most time-consuming (and tedious) aspects of programming in unmanaged environments.

A simple example of memory leak can be following.

int main(void)
    /* this is an infinite loop calling the malloc function which
     * allocates the memory but without saving the address of the
     * allocated place */
   while (malloc(50)); /* malloc will return NULL sooner or later, due to lack of memory */
   return 0;  /* free the allocated memory by operating system itself after program exits */
  • that wasn't the question. I know that. Check the linked url's comment section. Commented Sep 17, 2011 at 8:31
  • I am unsure what you are getting into. crashes a program by some other side-effect. We only use Memory leak when the crash occurs to do the scarcity of memory, which happens because of undeleted dynamic memory. Why you need to consider some other side-effects into Memory leaks Commented Sep 17, 2011 at 8:49
  • ohh great, somebody deleted all the comment section there so I cannot refer to that discussion anymore.. :/ Commented Sep 17, 2011 at 8:57


would you call something a simple memory leak that crashes a program by some other side-effect

Memory leaks can cause random bugs since memory may be assigned unexpected values.

causing a dead-lock by not freeing a lock?

Dead locks can be caused by memory which has been assigned unexpected values.

Further reading on this topic:

  1. http://en.wikipedia.org/wiki/Memory_pool
  2. http://en.wikipedia.org/wiki/Stack_overflow
  • khm. Is that a NO? Commented Sep 17, 2011 at 0:42
  • 1
    How exactly would a memory leak cause memory to have "arbitrary values"? Commented Sep 17, 2011 at 0:46
  • 2
    you should write your thoughts, I don't have a crystal ball here to figure out what you meant by those links... I would definitely not call a stack overflow a memory leak. Commented Sep 17, 2011 at 0:56
  • What do stack overflows have to do with memory leaks? And how would they cause memory to have "arbitrary values" in an environment with even the most basic safety features? Commented Sep 17, 2011 at 0:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.