Talk:Memory leak

message: These edits are not discussing a memory leak, but rather an application writing outside of allocated memory.  This is not the same thing as a memory leak, which is the topic of this article.  I intend to revert these changes, but wanted to discuss it first. – Doug Bell talk•contrib 08:52, 27 January 2006 (UTC)
replies: text: Whenever the topic of memory leaks came up among software engineers in various tech companies where I've worked since the late 1980s, it was understood that writing outside of allocated memory, with its attendant disastrous consequences, was a major factor.  I'm surprised that the article made no mention of this aspect of programming errors. --QuicksilverT @ 16:00, 27 January 2006 (UTC)
replies: text: While writing outside the bounds of allocated memory is certainly a common source of bugs in many languages, it's not a memory leak.  Leak refers to the syndrome of the available memory leaking away until there isn't enough left.  Can you provide any reference to out-of-bounds memory writes being refered to as a memory leak?  In 20+ years developing software, I never have heard the term used like that. – Doug Bell talk•contrib 16:26, 27 January 2006 (UTC)

text: This is not a memory leak. Certainly buffer overflow or access violation, but not memory leak. Memory leak is just allocating memory and not freeing it. --Juliano (T) 05:14, 2 March 2006 (UTC)
replies: text: Actually, a memory leak is allocating memory and then either not being able to release it (e.g., over-writing the pointer to the memory location), or possibly forgetting to release it.  If I allocate memory for a permanent data structure, that isn't a memory leak, but simply using memory. wrp103 (Bill Pringle) 14:50, 2 March 2006 (UTC)

text: I agree, and I cannot find internet resources to support this claim. If it is wrongly understood enough, it may be worth mentioning this confusion. I'm deleting the text as part of a general attempt to improve things (e.g. no mention of embedded systems or leaks within the operating system or automatic reclaiming on program termination...) Notinasnaid 10:18, 24 March 2006 (UTC)
thread_title:  January 26, 2005 additions by [[User:Hydrargyrum|Hydrargyrum]] 

message: I don't believe that it is servers that cause memory leak problems, but rather background tasks that run for long periods of time.  Typically they will run on servers, but they can just as easily be running on a workstation. wrp103 (Bill Pringle) 03:16, 4 June 2006 (UTC)
replies: text: It is also possible that the machine doesn't have enough resources, which is why it crashes.  There are a number of situations where a program might never give back memory, but rather handle memory itself.  The old, original WATFOR LISP that ran on an IBM 360 started by grabbing all available memory, and then kept track of things itself. wrp103 (Bill Pringle) 00:28, 10 August 2006 (UTC)
replies: text: No need to reach so far back: MSDOS programs still do that.  By default, DOS programs don't specify an upper bound on image load size, so the biggest unallocated memory chunk is allocated to the program.  Most programs administrate the space they don't need for static code and data as heap.  Not elegant behavior, but suitable for the environment.  Being a good memory neighbor becomes important with multiprocess environments.  Maybe the article should emphasize that?  —EncMstr 18:36, 10 August 2006 (UTC)
thread_title: Servers and Memory Leaks

message: Failure to release memory isn't in itself a memory leak. The memory is perhaps wasted and it may be an inefficient use, but the memory can still be accessed and released by the program. Perhaps we can add a condition to the first paragraph that says not only memory that is not released, but through programming errors "cannot be released" which is a more accurate description of a memory leak, as opposed to poor memory management.
Arthurrh 00:43, 31 October 2006 (UTC)
replies: text: Failure to release unused memory is what I understand by a memory leak. I think what you're describing is a more complicated kind of memory leak to fix, rather than the only kind. Any malloc without intended matching free is a leak. But let's not deal with opinions: do you have a source for this different definition? Notinasnaid 07:44, 31 October 2006 (UTC)

text: I'm not sure I see the distinction (though a better sourced article is welcome). We need to be careful in defining other sources as "wrong". This is a folk term, and unless there is a committee in charge of folk definitions, an encyclopedia needs to at least document major schools of thought. You seem to be saying though that it isn't a memory leak if an object was (for example) added to a linked list when it is created, but never freed from that list when it is no longer needed. Notinasnaid 21:30, 31 October 2006 (UTC)
thread_title: Failure to release

message: Can memory leakage be caused by faulty hardware?--ChrisJMoor 09:38, 28 March 2007 (UTC)
replies: text: That scenario can certainly happen, but I wouldn't consider it a memory leak.  That term, as used here, is the fault of a software error. wrp103 (Bill Pringle) 21:23, 31 March 2007 (UTC)

text: I see. It is sometimes the case that people blame their hardware for causing an apparent increase in memory usage/loss of performance over time, which is why I raised the issue. Since the science regards it as an error in software, perhaps this should be explicitly stated in the article? --ChrisJMoor 00:43, 2 April 2007 (UTC)
replies: text: I believe that is what the opening paragraph states.  People often blame the hardware because they don't want to believe the problem is in their software. ;^)  At the same time, it is a running joke that hardware errors are often fixed in the software. ;^) wrp103 (Bill Pringle) 01:56, 2 April 2007 (UTC)
thread_title: Hardware Problem?

message: I reverted a comment which added "(Please note items like embedded devices do not suffer this problem as they usually run dedicated programs from flash/rom) and as such usually very stable in memory usage)" because
#Running from Flash/ROM is a complete red herring; almost all embedded systems must also include RAM, and must manage it.
#Saying they are stable in memory usage seems to me to be saying that they are immune to memory leaks. Quite the opposite; if they don't have memory leaks it is because of careful programming to avoid it, hence the emphasis of the importance of this discipline to the programmers who work in this field. Notinasnaid 09:55, 9 May 2007 (UTC)
thread_title:  Not relevant to embedded systems? 

message: I added the vbscript example of a reference-oounting memory leak. The syntax highlighting engine apparently doesn't recognise vbscript, so I tagged it as vb. In this case, the vbscript is perfectly legal VB, but maybe the syntax highlighter needs updating. Dominic Cronin 22:15, 11 October 2007 (UTC)
thread_title:  VB example is actually vbscript 

message: I think memory leak problem is not relevant to Garbage Collected environments like Java, C# etc.
Because as long as you have a reference to memory you can use it and free it up.... It's however a brain leak of a programmer himself!!!
:But you can have references that can neither be used or accessed in practice. For example if you have a value in a dictionary that can only be found by an UUID/GUID which has been lost (much like loosing a pointer in C, except it's now a UUID). So I think you can have leaks in GC environment, but only at a "high level". Crashie (talk) 09:05, 22 June 2010 (UTC)
thread_title:  Not relevant to Java, C# etc. 

message: The statement "Whereas the C model requires the programmer to allocate and release resources explicitly" is overly broad and simply not true. The examples are slanted and poorly chosen: the C example using calloc could just as well have been written using for example an automatic int array (i.e. int array[1024];) or alloca, both of which would follow the RAII principle exactly like the C++ one. Likewise, the C++ example could just as easily have been written using the new operator, which would not follow the RAII principle. 89.181.3.50 (talk) 06:27, 13 March 2008 (UTC)
replies: text: Agreed. I have edited the section and believe it's better now. I removed the blanket statement regarding C (which was irrelevant anyway even if it were true, RAII is a design pattern, it's not language-specific), and added an explanation to the C example. I'm removing the disputed tag since I think I addressed the problem. Capi (talk) 07:47, 16 March 2008 (UTC)
thread_title:  [[Memory leak#RAII|RAII]] section is misrepresenting C 

message: Either the line at the end of the first paragraph of the Programming Issues needs removing or to be made to look less like it was tacked on the end by one of its developers. I'm not in a position to decide whether it is as worthy of mention as the other, provided, examples.
The [Page] lists the last update as December 07.  Lordandmaker (talk) 15:56, 27 November 2008 (UTC)
thread_title:  Windows Leaks Detector 

message: This article can be found by a redirect of Space leak. However, in the entire article, the term space leak does not occur. Is space leak a synonym for memory leak? If so, shouldn't it be mentioned in the introduction. If not, why does space leak redirect to here? Erwin (talk) 09:30, 3 January 2014 (UTC)
thread_title:  Space leak 

message: The image with the "sawtooth" pattern is in this context wrong and not a candidate for memory leak. A memory leak is visible when the basic value always rises. Here I am missing a reference to this statement.  — Preceding unsigned comment added by 193.108.8.100 (talk) 12:17, 20 August 2019 (UTC)
thread_title:  Image Sawtooth pattern