Date: Thu, 24 Jul 2003 13:55:24 -0400 From: Barney Wolff <barney@databus.com> To: Jason Andresen <jandrese@mitre.org> Cc: freebsd-stable@freebsd.org Subject: Re: malloc does not return null when out of memory Message-ID: <20030724175524.GA41037@pit.databus.com> In-Reply-To: <3F20170A.8080408@mitre.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> <3F20170A.8080408@mitre.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030724175524.GA41037>