Date: 07 May 2001 17:10:42 +0200 From: Dag-Erling Smorgrav <des@ofug.org> To: Dennis Glatting <dennis.glatting@software-munitions.com> Cc: Kris Kennaway <kris@obsecurity.org>, <freebsd-stable@frebsd.org>, <freebsd-current@FreeBSD.ORG> Subject: Re: pgm to kill 4.3 via vm Message-ID: <xzpy9s9mbyl.fsf@flood.ping.uio.no> In-Reply-To: <20010507074503.Y24943-100000@btw.plaintalk.bellevue.wa.us> References: <20010507074503.Y24943-100000@btw.plaintalk.bellevue.wa.us>
next in thread | previous in thread | raw e-mail | index | archive | help
Dennis Glatting <dennis.glatting@software-munitions.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpy9s9mbyl.fsf>