LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - General
User Name
Password
Linux - General This Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.

Notices

Reply
 
Search this Thread
Old 05-03-2008, 07:29 AM   #1
laucian
Member
 
Registered: Oct 2005
Distribution: Ubuntu 9.04
Posts: 124
Blog Entries: 2

Rep: Reputation: 15
how does linux deal with "memory leak" ?


hi everyone,

here is a small code that i have written

Code:
#include <stdio.h>

void f(void)
{
        void *s;
        s = malloc(50);
        return;

}

int main(void)
{
        while(1) f();
        return 0;

}
As you can see there is a memory leak in the code..when i run the program, everything gets frozen and after sometime the program gets killed.

I wonder how does the linux kernel deal with that?

thanks..
 
Old 05-03-2008, 10:08 AM   #2
PMorph
Member
 
Registered: Sep 2003
Distribution: Debian
Posts: 213

Rep: Reputation: 31
Google for "OOM killer"
 
Old 05-03-2008, 10:26 AM   #3
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269
Yes, and here's a good read on that topic:
http://lwn.net/Articles/104179/

It has a very nice, very funny analogy too

Last edited by H_TeXMeX_H; 05-03-2008 at 10:29 AM.
 
Old 05-03-2008, 10:28 AM   #4
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,083

Rep: Reputation: 1110Reputation: 1110Reputation: 1110Reputation: 1110Reputation: 1110Reputation: 1110Reputation: 1110Reputation: 1110Reputation: 1110
The Linux kernel doesn't and shouldn't attempt to detect or deal with memory leaks in a program.

The program keeps asking for more memory and the kernel keeps giving the program more memory until either the program runs out of virtual address space or the kernel runs out of memory that it is willing to give programs. (A 64 bit program won't run out of virtual address space first. A 32 bit program may run out of virtual address space first depending on how much physical memory and how much swap space you have and what else is using that memory at the time).

The Linux kernel does somewhat limit the damage to the rest of the system by such run away programs. It won't give away the last of its memory to an ordinary privilege program. (I don't recall the exact rules for how much is reserved and which tasks can tap that reserved memory).

But in an ordinary system the damage can be quite high. As you noticed, other tasks can be pushed out to the swap space first, so the system will seem frozen. Other tasks can even fail/crash if they make reasonable memory requests as the bad one reaches the limit of system memory. It is much harder for an OS to allocate memory and swapping I/O by priority or other sensible distribution, the way it can allocate CPU time. So a run away program taking too much memory can do more overall harm than one taking too much CPU time.

For a run away program as simple as your example, the program eventually crashes when its memory requests can't be met. Then all the memory comes back. That kind of leak within a program is contained to that program. When the program goes away, all the lost memory is recovered. Linux still correctly remembered which memory was allocated to that program, even though the program itself forgot.

In Windows there are more complex resource types that a program can leak that the OS doesn't recover when that program exits. If you have such leaks in programs in a Windows system (most people do) the only recovery is to reboot. Windows will manage a simple memory leak, as in your example, at least as well as Linux will and certainly will recover all of the memory when the program exits. I'm not sure of the details of the more complex leaks. I know programs can leak file handles in Windows in ways that aren't recovered on program exit (but I'm not sure exactly how). I know programs can leak attachments to DLL's that then remain until reboot (in my own use of Windows, that's the one that most often forces me to reboot, but I still don't know the exact application bug that makes it happen).

I don't know of any examples in Linux of an application leak of a complex resource (such as a file handle) that lasts until reboot rather than going away when the application owning the leaked resource goes away. I'm pretty sure anything I've ever done wrong in Windows resulting in the leak of a DLL attachment has been done wrong in Linux with a .so by me or some coworker and we never had any .so in Linux exhibit the problem that is common with DLL's in Windows.

Last edited by johnsfine; 05-03-2008 at 10:32 AM.
 
Old 05-03-2008, 11:08 AM   #5
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,083

Rep: Reputation: 1110Reputation: 1110Reputation: 1110Reputation: 1110Reputation: 1110Reputation: 1110Reputation: 1110Reputation: 1110Reputation: 1110
Quote:
Originally Posted by H_TeXMeX_H View Post
Yes, and here's a good read on that topic:
http://lwn.net/Articles/104179/

It has a very nice, very funny analogy too
Thanks. I found that interesting and informative. BUT, I also found most of it, especially the funny analogy, very misleading.

However you design it (short of somehow knowing in advance what will be the "run away" memory use programs) you can make a legitimate program crash because the buggy program used too much memory. The rest of it is just when and how and how likely, etc.

Most of it comes down to a question of when do you define a program as having allocated memory. The best example, fork, was mentioned in that discussion, but not given enough attention. When a program does a fork() has it just doubled its allocated memory? Or does it allocate that only when one side of the fork writes to the "copy on write" shared pages so they aren't shared any more.

I understand the theoretical beauty of saying the memory is always allocated on whatever system call makes it possible for some later access to really allocate memory. It is a little discomforting to define the allocation as that later event. But very few programs can defend themselves better from a failure in that system call than they can from a failure in that later access. Of those that could defend themselves better, most still don't. So in practical terms the event that matters for memory allocation is the event at which memory is actually taken. Defining it as an earlier event is less efficient with no real benefit.

The better analogy is to the days when airplane tickets were all refundable. When did a seat get committed to a passenger? When he bought the ticket or when he picked up the boarding pass? Of course the airline sold more tickets than they had seats. With all refundable tickets, lots of passengers didn't show up. The airline would lose too much money if they didn't over sell. Of course people would get inconvenienced and annoyed when more passengers showed up than expected. No system is perfect. Over selling tickets was a necessary practical policy. (I'm not ready to discuss the more complicated ethical question of over selling non refundable tickets).
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Response to "Why Wal-Mart Linux PC Is A Bad Deal" article LXer Syndicated Linux News 0 11-15-2007 04:50 PM
Measure "CPU load" and "memory consumption" of a process DaneelGiskard Programming 3 08-30-2007 11:43 AM
How to deal with filenames starting with "-" or "--"? [KIA]aze Linux - Newbie 2 07-08-2007 01:31 AM
How to deal with "We don't support Linux"? thisperson Linux - General 6 05-04-2006 02:26 AM
LXer: About the Firefox "memory leak" LXer Syndicated Linux News 0 02-14-2006 06:46 PM


All times are GMT -5. The time now is 12:37 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration