From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 10:55:25 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 6FAB737B401 for ; Thu, 24 Jul 2003 10:55:25 -0700 (PDT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AE5443F3F for ; Thu, 24 Jul 2003 10:55:24 -0700 (PDT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.9/8.12.9) with ESMTP id h6OHtOn8041442; Thu, 24 Jul 2003 13:55:24 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.9/8.12.9/Submit) id h6OHtOk1041441; Thu, 24 Jul 2003 13:55:24 -0400 (EDT) (envelope-from barney) Date: Thu, 24 Jul 2003 13:55:24 -0400 From: Barney Wolff To: Jason Andresen Message-ID: <20030724175524.GA41037@pit.databus.com> 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> <3F20170A.8080408@mitre.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F20170A.8080408@mitre.org> User-Agent: Mutt/1.4.1i 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:55:25 -0000 On Thu, Jul 24, 2003 at 01:27:38PM -0400, Jason Andresen wrote: > > The upshot seem to be that it is impossible to write a program that > handles out-of-memory errors gracefully with this scheme. Even if you > check all of your return values and configure exit paths for failed > mallocs, your program is still going to crash and die in a random > location without warning when memory fills up. On a production server, when you know what will be running, you can use ulimit to constrain each process's memory use, and malloc will happily return 0 if you hit a constraint. On a client machine, if you start getting these errors, the proper reaction is to configure more swap, or fix the program that has runaway memory use. Does anybody know if c++ exception handling on new would make recovery from out-of-swap practical? I have a feeling it ought to do the trick. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.