Subject: malloc standard behaviour.

From: Damiano Bolla <[email-masked]>
Date: Wed, 08 Apr 92 14:11:32 +0100

Well, let's go away for a bit from the /dev discussion :-)
I agree with everything abc will say, after all is not a big deal :-)
( I still like the idea of a device name with some meaning... )

Anyway. Iesterday I was recompiling Cron... Not much problems
Quite straightforward :-) BUT, just one problem

During the testing cron went on allocating memory and more memory
and using the said memory :-) I was watching the free space going down
and down and wondering what was going to happen. I was feeling safe
since cron was run interactively.

At some point the memory ( even the virtual one ) finished. I was waiting
for cron to die...... Wait,,,, Wait...., Wait... 10 minutes :-)
Cron don't die.... In the meantime the machine is almost hung 
It is not dead, it is alive, it is just so slow that you can't use it
and NO command can be run ( no memory available ).

You may wonder why this is in the standard list :-)
Well it has to do with how malloc is done.

As it is now malloc is like mach like it. You can malloc everything you
like you just run in trouble when you try to use it...

I don't like it, or better I would like to be able to choose between
this and the other possible behaviour ( the standard one ).

You may ask why I don't like it...
Suppose that my dear cron malloc some memory... malloc says OK. The
program run happly. At some point malloc try to use the memory.
What happens ? Cron die ? cron hung ? machine hung ?

Suppose one "not friendly" user want to give me trouble ....
Very easy, malloc (BIGNUM); for (x=0;x<BIG<x++) ptr[x]=0;
and trap the memfault signal.....

Not that this problem goes away with the old style malloc. But it probably
get less worse. I had to deal with this stuff in a 3B2 and if you 
make ps remaining in swap with the stiky bit you can find out who is
causing problems and "shut him" :-)

What I would like is:
A malloc that optionally control if the requested memory is available
and alloc for me all that memory.
A mach style malloc that don't trash the machine when the requested page
is not available...

The point is. Are most of you happy with the current implementation of
malloc ? ( after having considered the possible problems )

Damiano

I will try to start looking for a solution if some competent person
tell me that is reasonably simple to do. 
( Not that I have much time.... but I will try )

---

From: [email-masked] (Theodore Ts'o)
Date: Wed, 8 Apr 92 12:24:08 -0400

Date: Wed, 08 Apr 92 14:11:32 +0100
   From: Damiano Bolla <[email-masked]>

   What I would like is:

This really isn't a malloc problem; malloc is just a bit of user library
code that is calling sbrk().  The real problem here is that the VM isn't
really doing any bounds checking.  The sbrk() call never returns an
error, and if you reference a non-existent page, the VM will happily
create a zero-filled page for you.  That's the real problem.

There are two tacks we can take to solve this problem.  The first is  to
add BSD-style resource limits to the kernel. Actually, the getrlimit()
and setrlimit() calls are already in the kernel (I added them back when
I thought I was going to have to work on making core dumps work :-)  The
kernel just needs to enforce the limits in the task_struct structure.
Look at sys/resource.h for the relevent data structures.

The second tack is to improve the VM so that it will complain if you try
to reference a page that is between the end of your data segment and
your stack area.  This is not related to malloc() per se, except that
fixing this will fix similar problems when a program (such as compress)
goes wild and starts referencing a lot of non-existent pages.

							- Ted