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 

     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.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to