From owner-freebsd-current Mon May 7 13:37:55 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 A3C0B37B422 for ; Mon, 7 May 2001 13:37:49 -0700 (PDT) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id WAA53375; Mon, 7 May 2001 22:37:44 +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: <20010507112937.V47835-100000@btw.plaintalk.bellevue.wa.us> From: Dag-Erling Smorgrav Date: 07 May 2001 22:37:44 +0200 In-Reply-To: <20010507112937.V47835-100000@btw.plaintalk.bellevue.wa.us> Message-ID: Lines: 74 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: > On 7 May 2001, Dag-Erling Smorgrav wrote: > > > Dennis Glatting 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? > > > > Uh, when I perform a malloc() and get a NULL back? I dunno, what do you > call that? Address space exhaustion (which I incorrectly called "namespace exhaustion" in a previous mail - braino!), or a bug in malloc(). Consider the following program: #include #include int main(void) { int i; _malloc_options = "j"; for (i = 0; i < 4096; ++i) if (malloc(1048576) == NULL) err(1, "malloc() (i == %d)", i); exit(0); } The result may surprise you. > Why would it kill random processes as opposed to the offending process? Theoretically, it should kill the largest process around. I'm not sure it works like that in practice. > Regardless, the code shouldn't be crashing the kernel. Are you sure it does? Did you try running it on the console of a DDB-equipped system, press Ctrl-Alt-Esc, and find out what the kernel is doing when it appears frozen? > I don't really understand your point. Who really cares whether it is a > name space exhaustion or an exhaustion of virual memory or a fly sat on > the keyboard: malloc() was called and the kernel crashed. The kernel > should have failed the offending system call or killed the offending > application. Malloc() doesn't translate into a system call. It sometimes performs one or more system calls (mostly one of brk(), sbrk() and mmap()), and sometimes doesn't, depending largely on what kind of malloc() / free() activity there's been so far. Even when malloc() really does request memory from the kernel, what it really allocates is address space. The actual memory pages to fill that address space are allocated by the kernel as they are touched. > Is it reasonable to kill the operating system when these things happen? > No. The kernel should always be better behaved than the application. I didn't claim the contrary. I'm trying to show you that things don't work the way you think they do. Now be a good boy and go read the archives, it's all been discussed before. 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