From owner-freebsd-current Mon May 7 8:10:52 2001 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 03E1737B423 for ; Mon, 7 May 2001 08:10:48 -0700 (PDT) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id RAA51811; Mon, 7 May 2001 17:10:43 +0200 (CEST) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Dennis Glatting Cc: Kris Kennaway , , Subject: Re: pgm to kill 4.3 via vm References: <20010507074503.Y24943-100000@btw.plaintalk.bellevue.wa.us> From: Dag-Erling Smorgrav Date: 07 May 2001 17:10:42 +0200 In-Reply-To: <20010507074503.Y24943-100000@btw.plaintalk.bellevue.wa.us> Message-ID: Lines: 25 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. 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. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message