Date: 07 May 2001 17:59:43 +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: <xzpu22xm9ow.fsf@flood.ping.uio.no> In-Reply-To: <01050708414400.13646@kwijibo> References: <20010507074503.Y24943-100000@btw.plaintalk.bellevue.wa.us> <xzpy9s9mbyl.fsf@flood.ping.uio.no> <01050708414400.13646@kwijibo>
next in thread | previous in thread | raw e-mail | index | archive | help
Dennis Glatting <dennis.glatting@software-munitions.com> writes: > On Monday 07 May 2001 08:10 am, Dag-Erling Smorgrav wrote: > > 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? What is memory exhaustion? Namespace exhaustion will cause malloc() to fail. But FreeBSD overcommits memory, so exhaustion of physical and virtual memory will manifest itself as an unsatisfiable page fault, which will cause the kernel to start killing more-or-less-random processes until some memory is available again. > Explain the bug and malloc() behaviour. According to the malloc() man > page: The bug: I believe you meant "i -= j" when you wrote "i =- j". The result is that i becomes negative and in all likelihood you smash the malloc() arena. Regarding malloc(), you seem to believe that malloc() allocates *exactly* the amount you ask, no more, no less, and actually allocates physical or virtual memory. It doesn't. First of all, it allocates memory of its own for bookkeeping purposes, which your program doesn't account for. Second, it usually allocates a little bit more than you asked for, and keeps the leftovers for later. Third, it only allocates namespace. Actual memory (physical or virtual) is allocated by the kernel the first time you touch a page. What's more, your program does extra stuff (such as needlessly fork() / exec()ing sync(1) instead of just calling sync(2), which doesn't serve any purpose anyway, since virtual memory isn't managed by the file system code, so sync(2) doesn't affect it) which consumes memory, which further invalidates your results (for instance, memory exhaustion while running sync(1) could cause the kernel to randomly kill your program) > I assert memory exhaustion is would return "unsuccessful" on the > malloc() call, no? No, just namespace exhaustion, which your program won't even come close to. 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?xzpu22xm9ow.fsf>