From owner-freebsd-current Mon May 7 8:43: 1 2001 Delivered-To: freebsd-current@freebsd.org Received: from btw.plaintalk.bellevue.wa.us (btw.plaintalk.bellevue.wa.us [206.129.5.130]) by hub.freebsd.org (Postfix) with ESMTP id 3158637B423 for ; Mon, 7 May 2001 08:42:57 -0700 (PDT) (envelope-from dennis.glatting@software-munitions.com) Received: from kwijibo (kwijibi.pki2.com [206.129.5.152] (may be forged)) by btw.plaintalk.bellevue.wa.us (8.11.3/8.11.3) with SMTP id f47FfiE45909; Mon, 7 May 2001 08:41:44 -0700 (PDT) (envelope-from dennis.glatting@software-munitions.com) Content-Type: text/plain; charset="iso-8859-1" From: Dennis Glatting Organization: Software Munitions To: Dag-Erling Smorgrav Subject: Re: pgm to kill 4.3 via vm Date: Mon, 7 May 2001 08:41:44 -0700 X-Mailer: KMail [version 1.2] Cc: Kris Kennaway , , References: <20010507074503.Y24943-100000@btw.plaintalk.bellevue.wa.us> In-Reply-To: MIME-Version: 1.0 Message-Id: <01050708414400.13646@kwijibo> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday 07 May 2001 08:10 am, Dag-Erling Smorgrav wrote: > Dennis Glatting 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message