Very Computer

I wrote a program to test the OS stablity and I have seen that linux is
not too stabile.
I would like someone to explain me why the system crushed.

The program is:

main()
{
int *i;
while (1)
{
i=(int*) malloc(100*sizeof(int));

Quote:}
}

Quote:>I wrote a program to test the OS stablity and I have seen that linux is
>not too stabile.

Quote:>I would like someone to explain me why the system crushed.

Quote:

>The program is:

>main()
>{
>int *i;
>while (1)
>{
>i=(int*) malloc(100*sizeof(int));
>}
>}
>The system finish memory and do not kill the stupid program I wrote and
>then become unrecuperable.

--
Brian Wheeler

My _GUESS_ as to why this happens is that the syscall to increase memory
area ( sbrk(2)? ) takes a finite amount of time even in cases where there
is no memory, and the switching mechanism doesn't take that kernel time
into account?  

The reason for this, is already running programs (ie, I was running 'top'
while running a program of this nature) freeze as well.  

I WONDER why Unix didn't extend the concept of 5% free for root to memory
as well.  On a 64 meg system, that'd be 3 megs.. which should be enough to
run a program to kill the offending programs.  

This still doesn't help against poorly written daemons (ie sshd), which
you can use to hammer your machine with repeated connections (see octopus.c).

So, while linux _can_ be a stable environment, you have to sacrifice a lot of
flexibility to make it work as such ).

    Brian>   If you're afraid a user will try to run a
    Brian> program of this nature (or many processes, or open
    Brian> too many files, etc) you should investigate bash's
    Brian> ulimit command.

Out of curiosity I ran the program on my (crusty) 1.2.13
setup. It didn't crash the machine; but it did reach a point
where "ps" would segmentation-fault, and other utilities like
"ls" would die from memory exhaustion. Setting ulimits under
bash somehow didn't change matters (ulimit -Hm 100000; ulimit
-Hd 100000). Considering "ps" was failing, it would be hard for
a sysadmin to kill the errant process, except maybe by halting
the system.

gw

--
Greg Walker

Quote:> >>The system finish memory and do not kill the stupid program I wrote and
> >>then become unrecuperable.

> Actually, the system _shouldn't_ and _doesn't_ crash when you
> allocate all memory and try to allocate more.  I seem to recall a
> program doing exactly that as a means of detecting virtual
> memory. Even more so -- this program doesn't actually write to any
> pages, so they are never 'committed' (IF my understanding is correct
> -- I invite correction).

Quote:

> [...]

> I WONDER why Unix didn't extend the concept of 5% free for root to
> memory as well.  On a 64 meg system, that'd be 3 megs.. which should
> be enough to run a program to kill the offending programs.

Quote:

> So, while linux _can_ be a stable environment, you have to sacrifice
> a lot of flexibility to make it work as such ).

A question to the original poster - in what way did your system
"crash" - I tried a slightly modified version of your program on my
system (P100, RH 4.0, 2.0.28 kernel 64Mb Ram + 256Mb swap, no process
limits set). Whilst I couldn't start any new processes almost
everything which was running continued (one shell died - it probably
tried to allocate some memory) and all I had to do was type ^C in the
shell from which I started your program.

Really - complaining about this sort of thing is a bit like moaning
about your car because if you continue to drive until you're out of
fuel you then have to walk home.

Regards

Paul.

|> >>I would like someone to explain me why the system crushed.
|> >
|> >      You've used up all the memory in the system, and not checked for
|> >errors, so your program tries to allocate more.  When the system can't allocate
|> >any more, it crashes.
|> >>The program is:
|> >>
|> >>main()
|> >>{
|> >>int *i;
|> >>while (1)
|> >>{
|> >>i=(int*) malloc(100*sizeof(int));
|> >>}
|> >>}
|> >>The system finish memory and do not kill the stupid program I wrote and
|> >>then become unrecuperable.
|>
|> Actually, the system _shouldn't_ and _doesn't_ crash when you allocate all
|> memory and try to allocate more.  I seem to recall a program doing exactly
|> that as a means of detecting virtual memory. Even more so -- this program
|> doesn't actually write to any pages, so they are never 'committed' (IF my
|> understanding is correct -- I invite correction).  
|>
|> My _GUESS_ as to why this happens is that the syscall to increase memory
|> area ( sbrk(2)? ) takes a finite amount of time even in cases where there
|> is no memory, and the switching mechanism doesn't take that kernel time
|> into account?  

In the above example the pages _are_ commited.  The allocated chunks are much
smaller than a page; malloc uses some bytes immediately before the returned
chunk to store data about the chunk.  This means that all pages allocated
via brk(2) / mmap(2) in above example are actually being commited.

|> The reason for this, is already running programs (ie, I was running 'top'
|> while running a program of this nature) freeze as well.  
|>
|> I WONDER why Unix didn't extend the concept of 5% free for root to memory
|> as well.  On a 64 meg system, that'd be 3 megs.. which should be enough to
|> run a program to kill the offending programs.  
|>
|> This still doesn't help against poorly written daemons (ie sshd), which
|> you can use to hammer your machine with repeated connections (see octopus.c).
|>
|> So, while linux _can_ be a stable environment, you have to sacrifice a lot of
|> flexibility to make it work as such ).

Try using resource limits.

  Ralf

--
74 a3 53 cc 0b 19