Dennis Glatting <[EMAIL PROTECTED]> writes:
> On 7 May 2001, Dag-Erling Smorgrav wrote:
>
> > Dennis Glatting <[EMAIL PROTECTED]> writes:
> > > On Monday 07 May 2001 08:10 am, Dag-Erling Smorgrav wrote:
> > > > malloc() will return NULL only if you hit a resource limit or exhaust
> > > > address space. There may or may not be memory (real or virtual)
> > > > available at that time.
> > > Isn't memory exhaustion a resource limit?
> >
> > What is memory exhaustion?
> >
>
> Uh, when I perform a malloc() and get a NULL back? I dunno, what do you
> call that?
Address space exhaustion (which I incorrectly called "namespace
exhaustion" in a previous mail - braino!), or a bug in malloc().
Consider the following program:
#include <err.h>
#include <stdlib.h>
int
main(void)
{
int i;
_malloc_options = "j";
for (i = 0; i < 4096; ++i)
if (malloc(1048576) == NULL)
err(1, "malloc() (i == %d)", i);
exit(0);
}
The result may surprise you.
> Why would it kill random processes as opposed to the offending process?
Theoretically, it should kill the largest process around. I'm not
sure it works like that in practice.
> Regardless, the code shouldn't be crashing the kernel.
Are you sure it does? Did you try running it on the console of a
DDB-equipped system, press Ctrl-Alt-Esc, and find out what the kernel
is doing when it appears frozen?
> I don't really understand your point. Who really cares whether it is a
> name space exhaustion or an exhaustion of virual memory or a fly sat on
> the keyboard: malloc() was called and the kernel crashed. The kernel
> should have failed the offending system call or killed the offending
> application.
Malloc() doesn't translate into a system call. It sometimes performs
one or more system calls (mostly one of brk(), sbrk() and mmap()), and
sometimes doesn't, depending largely on what kind of malloc() / free()
activity there's been so far.
Even when malloc() really does request memory from the kernel, what it
really allocates is address space. The actual memory pages to fill
that address space are allocated by the kernel as they are touched.
> Is it reasonable to kill the operating system when these things happen?
> No. The kernel should always be better behaved than the application.
I didn't claim the contrary. I'm trying to show you that things don't
work the way you think they do. Now be a good boy and go read the
archives, it's all been discussed before.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
