From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 11:29:53 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 C24C237B401 for ; Fri, 25 Jul 2003 11:29:53 -0700 (PDT) Received: from smtp6.wanadoo.nl (smtp6.wanadoo.nl [194.134.35.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1541D43F3F for ; Fri, 25 Jul 2003 11:29:53 -0700 (PDT) (envelope-from steve@sohara.org) Received: from ams-gw.sohara.org (rot2-p1174.dial.wanadoo.nl [62.234.202.150]) by smtp6.wanadoo.nl (Postfix) with SMTP id 6A22176ACA; Fri, 25 Jul 2003 20:29:50 +0200 (CEST) Date: Fri, 25 Jul 2003 20:29:46 +0200 From: Steve O'Hara-Smith To: Peter Jeremy Message-Id: <20030725202946.0e554369.steve@sohara.org> In-Reply-To: <20030724213707.GU430@gsmx07.alcatel.com.au> 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> <20030724213707.GU430@gsmx07.alcatel.com.au> X-Mailer: Sylpheed version 0.9.3 (GTK+ 1.2.10; i386-portbld-freebsd4.8) X-Face: %]+HVL}K`P8>+8ZcY-WGHP6j@&mxMo9JH6_WdgIgUGH)JX/usO0%jy7T~IVgqjumD^OBqX,Kv^-GM6mlw(fI^$"QRKyZ$?xx/ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: barney@databus.com 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: Fri, 25 Jul 2003 18:29:54 -0000 On Fri, 25 Jul 2003 07:37:07 +1000 Peter Jeremy wrote: PJ> I'd suggest adding code in the "malloc_overcommit" path to touch stack PJ> that is likely to be used, close to the top of {m,c,re}alloc(). Sounds like a good move. PJ> There's a gcc-specific extension "__builtin_frame_address()" that will PJ> let you do this. This ensures that the stack pages you need are Urk - someone who understands the layout of the stack and can estimate the probable use had better look at doing that if it's going to happen. As for freeing the already allocated memory - what a good idea :) PJ> present before you try to sbrk() the data. There may still be other PJ> corner cases I've missed. PJ> PJ> Cleanly recovering in all cases when there is no additional memory PJ> available is a very hard problem. Most of the suggested fixes This is true - OTOH the OP would probably be much happier if malloc could be made to return NULL nearly always when memory can't be allocated, with a small probability of crashing. It looks like between us we might manage to produce a patch that will do that much. -- C:>WIN | Directable Mirrors The computer obeys and wins. |A Better Way To Focus The Sun You lose and Bill collects. | licenses available - see: | http://www.sohara.org/