Memory Leak: Difference between revisions
Yuron [PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
pc>Yuron No edit summary |
||
Line 1: | Line 1: | ||
{{#set: Priority=1 | Summary=A fault whereby memory - a valuable resource - is claimed and then forgotten about, thus, typically, causing an application to request more and more of this resource.}}<!-- | {{#set: Priority=1 | Summary=A fault whereby memory - a valuable resource - is claimed and then forgotten about, thus, typically, causing an application to request more and more of this resource.}}<!-- | ||
-->{{#invoke:Dependencies|add|Dynamic Memory Allocation,3}} | -->{{#invoke:Dependencies|add|Dynamic Memory Allocation,3}} | ||
A so-called “[https://en.wikipedia.org/wiki/Memory_leak memory leak]” is a case | A so-called “[https://en.wikipedia.org/wiki/Memory_leak memory leak]” is a case where [[Memory_Management|dynamically allocated memory]] is not released when it is finished with. This is normally a result of bad programming practice. | ||
where [[Memory_Management|dynamically allocated memory]] is not | |||
released when it is finished with. This is normally a result of bad | |||
programming practice. | |||
The effect is often that more memory is claimed instead of recycling | The effect is often that more memory is claimed instead of recycling the existing resource. This will cause a slowdown as a process’ memory ‘footprint’ increases (resulting in extra [[paging]]) and, eventually, a crash of that process because there is no more resource for it. | ||
the existing resource. This will cause a slowdown as a process’ | |||
memory ‘footprint’ increases (resulting in extra | |||
[[paging]]) and, eventually, a crash of that process because | |||
there is no more resource for it. | |||
<blockquote> | <blockquote> | ||
In the worst case, other processes and even the O.S. could crash due | In the worst case, other processes and even the O.S. could crash due to an apparent lack of resource. | ||
to an apparent lack of resource. | |||
</blockquote> | </blockquote> | ||
Memory leaks are (sadly!) not uncommon in applications processes. An | Memory leaks are (sadly!) not uncommon in applications processes. An operating system such as Unix <em>also</em> keeps track of the memory allocated to each process and will recover <em>every</em> resource it claimed when it terminates. This makes a leak less likely to be a fatal problem. | ||
operating system such as Unix <em>also</em> keeps track of the memory | |||
allocated to each process and will recover <em>every</em> resource it claimed | |||
when it terminates. This makes a leak less likely to be a fatal | |||
problem. | |||
---- | ---- | ||
{{PageGraph}} | {{PageGraph}} | ||
{{Category|Memory}} | {{Category|Memory}} |
Revision as of 13:19, 2 August 2019
Depends on | Dynamic Memory Allocation |
---|
A so-called “memory leak” is a case where dynamically allocated memory is not released when it is finished with. This is normally a result of bad programming practice.
The effect is often that more memory is claimed instead of recycling the existing resource. This will cause a slowdown as a process’ memory ‘footprint’ increases (resulting in extra paging) and, eventually, a crash of that process because there is no more resource for it.
In the worst case, other processes and even the O.S. could crash due to an apparent lack of resource.
Memory leaks are (sadly!) not uncommon in applications processes. An operating system such as Unix also keeps track of the memory allocated to each process and will recover every resource it claimed when it terminates. This makes a leak less likely to be a fatal problem.