From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 10:19:14 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9657037B40E for ; Thu, 24 Jul 2003 10:19:14 -0700 (PDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD95743F93 for ; Thu, 24 Jul 2003 10:19:13 -0700 (PDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.9/8.12.8) with ESMTP id h6OHJ8Ra015569; Thu, 24 Jul 2003 13:19:08 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.2.0.9.0.20030724114115.0849c450@209.112.4.2> X-Sender: mdtpop@209.112.4.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 24 Jul 2003 13:20:26 -0400 To: Andrew Reilly From: Mike Tancsa In-Reply-To: <3F1F817E.7040504@bigpond.net.au> References: <5.2.0.9.0.20030723234250.052821e8@192.168.0.12> <20030723173427.GA72876@vmunix.com> <20030723173427.GA72876@vmunix.com> <5.2.0.9.0.20030723234250.052821e8@192.168.0.12> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: By Sentex Communications (lava/20020517) cc: freebsd-stable@freebsd.org Subject: Re: malloc does not return null when out of memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2003 17:19:15 -0000 At 04:49 PM 24/07/2003 +1000, Andrew Reilly wrote: >Mike Tancsa wrote: > >>At 08:15 PM 7/23/2003 -0700, Kris Kennaway wrote: >> >>>On Wed, Jul 23, 2003 at 01:34:27PM -0400, Gabor wrote: >>> >>> > Here is the tail end of the output. It dies when trying to poke at >>> > the memory using memset. If I just malloc without the memset, it >>> > never even dies. >>> >>>Ah, the annual "memory overcommit" thread. I thought we were overdue >>>for one. >> >> >> >>But why does the man page for malloc (3) say, >> >> If malloc() fails, a NULL pointer is returned. > > >Because that's what happens. See the subthread with the ulimit examples. > >In the cases being cited, the malloc itself is not failing, because it is >able to return a pointer to a chunk of *VM*. The problem occurrs later, >when the program attempts to read or write to that memory, and it doesn't >occur because malloc was wrong, but because no other process has exited or >unmapped something in the mean-time, to free up a page to back that >address space. Thanks for the clarification. I guess it would be helpful if there was an * or caveat perhaps in the man page after "If malloc() fails, a NULL pointer is returned." I see what you mean that it "never fails" in the strict sense, but there is a potential for a failure in the process of memory allocation and usage which I think is helpful for the programmer / user to understand. What if something like this were added to /usr/share/man/man3/malloc.3. Note: malloc will return a pointer to memory even when there is not enough actual physical memory and swap to handle the request. It will only fail once you actually try to access that allocation and if by that time the system has not freed up memory from elsewhere to honor that request. The idea behind this strategy being that at any given time programs will ask for more memory than there is actually available, and more memory than they actually need. By having the VM tell the program, "yes, you can have this memory allocation", the chances are by the time the program actually uses the memory, it will be available as some other program has freed up their memory allocation. For further information, see ***** ---Mike