On Monday 07 May 2001 08:10 am, Dag-Erling Smorgrav wrote:
> Dennis Glatting <[EMAIL PROTECTED]> writes:
> > I am intentionally testing at the limits to see what happens,
> > usually interesting things. :) In this case, the application is
> > well behaved (in the error proccesing sense): it'll exit, thus
> > releasing its memory resources, when the kernel reports a memory
> > allocation failure.
>
> No.
>
> 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?
> Plus, your program doesn't even do what you think it does (because a)
> it has at least one significant bug and b) malloc() doesn't behave
> the way you think it does). And even if it did, the /dev/random
> stuff is pointless, you can achieve the same effect by setting every
> byte you allocate (possibly even just the first byte of every chunk)
> to 0.
>
/dev/random is left over from a different test and isn't relevant.
Explain the bug and malloc() behaviour. According to the malloc() man
page:
RETURN VALUES
The malloc() and calloc() functions return a pointer to
the allocated memory if successful; otherwise a NULL
pointer is returned and errno is set to ENOMEM.
I assert memory exhaustion is would return "unsuccessful" on the
malloc() call, no?
> To really test what you think your program tests, you should mmap()
> an amount of memory larger than RAM + swap and touch every page.
> Even then, the result will be a SIGSEGV, not a graceful termination.
>
> DES
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
