Talk:Memory leak

January 26, 2005 additions by Hydrargyrum

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)

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. --Quicksilver^{T @} 16:00, 27 January 2006 (UTC)

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)

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)

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)

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)

Servers and Memory Leaks

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)

er, first time attempt at an edit, so (i know this won't work) be nice. excellently written article, it seems to me (simple for a non IT person to understand), but this: "Most modern operating systems on general purpose computers use a hard disk to provide virtual memory. The effect once RAM has run out is increasing use of hard disk. The hard disk can in turn eventually run out, but usually the performance of the application and/or system will have become so slow that they will be considered to have failed before that point.

If a system crashes simply because an application has continually asked for more memory, this would be considered poor system design or a bug." seems like a tautology. —The preceding unsigned comment was added by 66.117.148.50 (talk • contribs) .

An application that continues to allocate memory without giving some up is poorly designed. It is very convenient to implement, and might be appropriate for programs which know the aggregate allocation is acceptably small.

I don't think it's quite a tautology: the distinction is that the platform itself might be blamed for poor performance ("Maybe the disk needs defragging", or "Maybe time for a CPU upgrade") and not the offending application. —EncMstr 23:20, 9 August 2006 (UTC)

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)

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)

Failure to release

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)

I'm having trouble understanding the distinction. Do you mean a substandard implementation of a heap manager? Memory which is mismanaged or wasted is still memory not to be acquired in the usual way. Correcting the problem still requires engineering effort, whether that's upgrading one component or the other, who cares? — EncMstr 00:53, 31 October 2006 (UTC)

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)

"Memory leaks are often thought of as failures to release unused memory by a computer program. Strictly speaking, that behaviour is just more memory consumption. A memory leak occurs when the program loses even the ability to free the memory." http://dictionary.laborlawtalk.com/Memory_leak is one source for it. There are many places on the web that define it more broadly, as this paragraph mentions, but they are incorrect. Arthurrh 20:28, 31 October 2006 (UTC)

Also look at: "Final note: Some people have strong opinions about this. "Whenever memory is allocated but not returned to the system, this is a leak per definition." That's like defining a leak as " whenever water from the sea enters the ship". Would you really accept an prohibition of showering, just because of some overzealous toolmakers?" from http://butunclebob.com/ArticleS.JamesGrenning.CppTestToolsMemoryLeakDetector Arthurrh 20:35, 31 October 2006 (UTC)

Further discussion at: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/160774 Arthurrh 20:38, 31 October 2006 (UTC)

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)

Hardware Problem?

Can memory leakage be caused by faulty hardware?--ChrisJMoor 09:38, 28 March 2007 (UTC)

• Not as it is defined here, unless the hardware itself contains software components with this programming error. Notinasnaid 11:10, 28 March 2007 (UTC)

That so? What about execution errors in a process that changes its memory usage that are caused by the hardware itself? Probably clutching at straws here but its worth asking. I suppose what I am asking is whether memory leakage is a possible outcome of a 'hard' computer error here.--ChrisJMoor 20:51, 31 March 2007 (UTC)

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)

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)

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)

Not relevant to embedded systems?

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

1. Running from Flash/ROM is a complete red herring; almost all embedded systems must also include RAM, and must manage it.
2. 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)

VB example is actually vbscript

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)

Citations for reference counting section

Bill Pringle has alerted me to the need for citations in my recent contribution. Here is my response.

In general, I think what I added is fairly uncontroversial, and there are probably millions of programmers in the world who are directly familiar with the kind of leaks I have described. My description comes as much from working actively as a programmer for the last twenty years as from any specific citeable source. I wrote the code example myself to illustrate the point.

It's definitely not controversial to state that reference counting "garbage collection" systems don't cope well with cyclic references. With some fairly minor additions, the example code could be expanded to a working experimental demonstration of a cyclic reference memory leak. It might be more controversial to suggest that mark and sweep systems are more costly, as perhaps that's implementation-specific. (I hope it's clear that I'm using the term "costly" in the sense of "requiring more resources or processing effort"). In practice, mark and sweep systems tend to be quite efficient when they aren't collecting as they don't actually need to do anything. This gain is offset, though, by fairly heavy use of resources when a GC actually takes place.

If anyone is an authority on Javascript, Douglas Crockford is. Perhaps a link to his page (http://javascript.crockford.com/memory/leak.html) would be useful in the context of my note about AJAX programming techniques in browsers.

As for AJAX techniques keeping a given DOM alive for longer than traditional web pages, well that's basically what AJAX is: you keep a single page loaded, and then update it in the browser using callbacks to the server. So I don't think that's a controversial statement either. Perhaps a link to AJAX (Programming) would be sufficient.

So in summary, I accept that there's room for improvement in this piece, but I'm not sure quite how that should be done. Where the nature of the contribution is uncontroversial, I think we can rely as much on the wiki process as on citations. I don't notice anyone rushing to add citations in support of the battle of Hastings taking place in 1066.

Dominic Cronin 23:08, 23 October 2007 (UTC)

One of the strange things about Wikipedia that takes a while to get used to is that Wikipedia is more interested in verifiability than truth. See WP:VERIFY. -- wrp103 (Bill Pringle) ^(Talk) 02:09, 24 October 2007 (UTC)

Well fine too, but on this particular page we're trying to describe a commonly acknowledged phenomenon in software development. Now presumably the entry on the battle of Hastings should refer to some very old historical texts and specify where they are held. We'll skate over the fact that it doesn't; the fact remains that for the battle of Hastings, there presumably are such texts, and numerous authoritative interpretations of them. In computer science it's a little bit different. What makes an authority? e.g. I think Doug Crockford is, but who's to say I'm right?

Therein lies the difficulty. I'd welcome other viewpoints on this, but right now, the only way forward I can think of is to say that different types of information must have different standards of verifiability. Otherwise, what would you suggest? Should I take my contribution out? That would be a shame, as it covers a very common type of memory leak which is otherwise ignored. Dominic Cronin 06:51, 24 October 2007 (UTC)

Citations must refer to a reliable source (WP:RS). That doesn't mean the opinion cited is correct, only that it accurately represents a recognized opinion. So, if you can find what appears to be a respectable site maintained by somebody with credentials, then add the citation to the article. If you can find an opposing opinion, then add it for balance. Wash, rinse, repeat. ;^) -- wrp103 (Bill Pringle) ^(Talk) 00:25, 25 October 2007 (UTC)

OK - I think I have the answer to this. The crux of it is that the material I added has neither been challenged nor is it likely to be challenged, and therefore according to WP:Verifiability, doesn't require citations. If no citations are required, then of course their reliability is moot. In other words, my earlier notes about uncontroversial contributions are already covered by Wikipedia policy. On this basis, I'm going to remove the "citation required" tags. —Preceding unsigned comment added by DominicCronin (talk • contribs) 13:51, 9 December 2007 (UTC)

Not relevant to Java, C# etc.

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)

RAII section is misrepresenting C

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)

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)

Windows Leaks Detector

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)

Space leak

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)

After three years of inactivity, I have added a sentence about the difference between memory leaks and space leaks. Erwin (talk) 23:43, 26 May 2017 (UTC)

Image Sawtooth pattern

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)