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.
>
> 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.
>
> 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.
Regardless, the machine should recover once all (trouble) programs have
been killed.
--
Daniel C. Sobral (8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Caffeine is proof that God hates mornings too
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
