From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 14:37:24 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 E26FF37B401 for ; Thu, 24 Jul 2003 14:37:23 -0700 (PDT) Received: from alcanet.com.au (mail2.alcanet.com.au [203.62.196.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D99643F75 for ; Thu, 24 Jul 2003 14:37:22 -0700 (PDT) (envelope-from peter.jeremy@alcatel.com.au) Received: from sydsmtp01.alcatel.com.au (IDENT:root@localhost.localdomain [127.0.0.1])h6OLbAx3002267; Fri, 25 Jul 2003 07:37:11 +1000 Received: from gsmx07.alcatel.com.au ([139.188.20.247]) by sydsmtp01.alcatel.com.au (Lotus Domino Release 5.0.12) with ESMTP id 2003072507370996:75451 ; Fri, 25 Jul 2003 07:37:09 +1000 Received: from gsmx07.alcatel.com.au (localhost [127.0.0.1]) by gsmx07.alcatel.com.au (8.12.9/8.12.9) with ESMTP id h6OLb97d085825; Fri, 25 Jul 2003 07:37:09 +1000 (EST) (envelope-from peter.jeremy@alcatel.com.au) Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.12.9/8.12.9/Submit) id h6OLb730085824; Fri, 25 Jul 2003 07:37:07 +1000 (EST) (envelope-from peter.jeremy@alcatel.com.au) Date: Fri, 25 Jul 2003 07:37:07 +1000 From: Peter Jeremy To: "Steve O'Hara-Smith" Message-ID: <20030724213707.GU430@gsmx07.alcatel.com.au> Mail-Followup-To: Steve O'Hara-Smith , Barney Wolff , freebsd-stable@freebsd.org References: <20030723173427.GA72876@vmunix.com> <20030723173427.GA72876@vmunix.com> <5.2.0.9.0.20030723234250.052821e8@192.168.0.12> <20030724070936.GA16762@rot13.obsecurity.org> <3F1FF81F.5050701@mac.com> <20030724164522.GA39964@pit.databus.com> <20030724201702.6667b707.steve@sohara.org> Mime-Version: 1.0 In-Reply-To: <20030724201702.6667b707.steve@sohara.org> User-Agent: Mutt/1.4.1i X-MIMETrack: Itemize by SMTP Server on SYDSMTP01/AlcatelAustralia(Release 5.0.12 |February 13, 2003) at 25/07/2003 07:37:10 AM,|February 13, 2003) at 25/07/2003 07:37:11 AM, Serialize complete at 25/07/2003 07:37:11 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline cc: Barney Wolff 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 21:37:24 -0000 On 2003-Jul-24 20:17:02 +0200, Steve O'Hara-Smith wrote: >On Thu, 24 Jul 2003 12:45:22 -0400 >Barney Wolff wrote: > >BW> On Thu, Jul 24, 2003 at 11:15:43AM -0400, Chuck Swiger wrote: >BW> > >BW> > +/* write a single byte per page to disable overcommit behavior */ >BW> > +static int malloc_overcommit; >BW> >BW> Won't this merely die in malloc, not return 0? > > Yes - it needs to trap the SEGV as well to produce the wanted >behaviour, something like: ... > Where ocsighandleron() installs a SEGV handler that sets ocsignalled >when called and ocsighandleroff() installs the original one. This still can't handle all cases. Handling the SEGV may require additional memory - particularly stack - which isn't available. You also need to free() the memory before returning NULL. This may allow a future smaller malloc to succeed. I'd suggest adding code in the "malloc_overcommit" path to touch stack that is likely to be used, close to the top of {m,c,re}alloc(). There's a gcc-specific extension "__builtin_frame_address()" that will let you do this. This ensures that the stack pages you need are present before you try to sbrk() the data. There may still be other corner cases I've missed. Cleanly recovering in all cases when there is no additional memory available is a very hard problem. Most of the suggested fixes generally rely on the kernel providing a warning when the VM system is under stress but can still satisfy some requests. Unfortunately, I don't think any of them included the necessary patches. I think the idea of adding entries to both the FAQ and malloc(3) explaining what happens is good. The text that was posted is probably "good-enough" for a start - all that's needed is a decent URL to provide a more detailed explanation to replace the '****'. Peter