Date: Mon, 7 May 2001 08:41:44 -0700 From: Dennis Glatting <dennis.glatting@software-munitions.com> To: Dag-Erling Smorgrav <des@ofug.org> 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: <01050708414400.13646@kwijibo> In-Reply-To: <xzpy9s9mbyl.fsf@flood.ping.uio.no> References: <20010507074503.Y24943-100000@btw.plaintalk.bellevue.wa.us> <xzpy9s9mbyl.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 07 May 2001 08:10 am, Dag-Erling Smorgrav wrote:
> 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.
>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01050708414400.13646>