[ACCEPTED]-The Best Memory Leak Definition-definition

There are two definitions (at least for 16 me):

Naive definition: Failure to release unreachable memory, which can 15 no longer be allocated again by any process 14 during execution of the allocating process. This 13 can mostly be cured by using GC (Garbage 12 Collection) techniques or detected by automated 11 tools.

Subtle definition: Failure to release reachable memory which 10 is no longer needed for your program to 9 function correctly. This is nearly impossible 8 to detect with automated tools or by programmers 7 who are not familiar with the code. While 6 technically it is not a leak, it has the 5 same implications as the naive one. This 4 is not my own idea only. You can come across 3 projects that are written in a garbage collected 2 language but still mention fixing memory 1 leaks in their changelogs.

Allocated memory that cannot be used because 1 the reference to it has been lost.

Definition: Failure to release memory after allocation.

0

The process in which memory resource are 10 allocated and not properly released once 9 no longer required, often introduced through 8 bad coding practices.

There are built in 7 ways in some languages to help prevent them, although 6 the best way to avoid them is through diligent 5 observation of code execution paths and 4 code reviews. Keeping methods short and 3 singularly purposed helps to keep resource 2 usage tightly scoped and less prone to get 1 lost in the shuffle, as well.

There are two ways a memory leak may be 36 defined.

First, if data is not freed when 35 there are no longer has any references to 34 it, that data is unreachable (unless you 33 have some corrupt pointer or read past the 32 data in a buffer or something). Basically, if 31 you don't free/delete data allocated on 30 the heap, it becomes unusable and simply 29 wastes memory.

There may be cases where a 28 pointer is lost but the data is still accessible. For 27 example, if you store the pointer in an 26 int, or store an offset to the pointer (using 25 pointer arithmetic), you can still get the 24 original pointer back.

In this first definition, data 23 is handled by garbage collectors, which 22 keep track of the number of references to 21 the data.

Second, memory is essentially leaked 20 if it is not freed/deleted when last used. It 19 may be referenced, and immediately free-able, but 18 the mistake has been made not to do so. There 17 may be a valid reason (e.g. in the case 16 where a destructor has some weird side effect), but 15 that indicates bad program design (in my 14 opinion).

This second type of memory leaking 13 often happens when writing small programs 12 which use file IO. You open the file, write 11 your data, but don't close it once you're 10 done. The FILE* may still be within scope, and 9 easily closeable. Again, there may be some 8 reason for doing this (such as locking write 7 access by other programs), but to me that's 6 a flag of bad design.

In this second definition, data 5 is not handled by garbage collectors, unless 4 the compiler/interpreter is smart (or dumb) enough 3 to know it won't be used any longer, and 2 this freeing the data won't cause any side 1 effects.

w:

In computer science, a memory leak is a 7 particular type of unintentional memory 6 consumption by a computer program where 5 the program fails to release memory when 4 no longer needed. This condition is normally 3 the result of a bug in a program that prevents 2 it from freeing up memory that it no longer 1 needs.

Memory that is not deallocated when it is 18 no longer needed, and is no longer "reachable". For 17 instance, in unmanaged code, if I use "new" to 16 instantiate an object, but I don't use "delete" when 15 I'm done with it (and my pointer has gone 14 out of scope or something).

The best way 13 to prevent them probably depends on who 12 you ask and what language you are using. Garbage 11 collection is a good solution for it, of 10 course, but there may be some overhead associated 9 with this, which isn't a big deal unless 8 you performance is your primary concern. Garbage 7 collection may not always be available, again, depending 6 on the language you are using.

Alternatively, you 5 can make sure you have the appropriate deletes 4 and/or destructors in place. There's a 3 lot of methods and tools to detect memory 2 leaks as well, but this will depend on the 1 language and/or IDE you are using.

Memory Leak: Failing to free memory that you no longer 2 need before either:

• The program terminates
• Additional memory is allocated

Best way to prevent Memory Leaks: Free memory as soon 1 as it is no longer needed.

All the definitions given here (at the time 19 I wrote this, we have gotten better answers 18 since) fail to address one borderline case:

You 17 have a singleton that allocates memory upon 16 creation and this memory is normally held 15 as long as the program is running even though 14 the current use is done and it's unknown 13 whether any future use will ever be made 12 or not. This is generally done because 11 of the overhead of recreating it.

By the 10 "fail to free when done with it" standard 9 this would be considered a leak and I've 8 seen leak-reporting tools call such things 7 leaks as the memory was still in use. (And 6 in fact the code may not contain code capable 5 of cleaning the object up.)

However, I have 4 encountered code of this nature in compiler 3 libraries before even when the cost of recreating 2 the object isn't all that great.

Leak or 1 not?

Here are some techniques for preventing 14 / detecting memory leaks:

1. Consider your algorithm in terms of memory consumption. Other respondents 13 have mentioned the fact that you don't have 12 to lose the pointer to an allocated item 11 to leak memory. Even if your implementation 10 contains zero pointer bugs, you can still 9 effectively leak memory if you hold onto 8 allocated items long after you actually 7 need them.

2. Profile your application. You can use memory debugger tools 6 like Valgrind or Purify to find leaks.

3. Black-box testing. Watch 5 what happens to your compiled code after 4 you feed it large data sets, or allow it 3 to run for long periods of time. See if 2 its memory footprint has a tendency to grow 1 without limit.