From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 16:51: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 64B8537B401 for ; Thu, 24 Jul 2003 16:51:25 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99E0143F85 for ; Thu, 24 Jul 2003 16:51:24 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9/8.12.9) with ESMTP id h6ONpGM7055649; Thu, 24 Jul 2003 16:51:21 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200307242351.h6ONpGM7055649@gw.catspoiler.org> Date: Thu, 24 Jul 2003 16:51:16 -0700 (PDT) From: Don Lewis To: cswiger@mac.com In-Reply-To: <3F20692E.2060107@mac.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii 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 23:51:25 -0000 On 24 Jul, Chuck Swiger wrote: > Muttley wrote: >> Yes, I thought briefly about something like this. >> >> Then I thought 'there's a race condition'. > > Where? The FreeBSD implementation is wrapped in a THREAD_LOCK()...? > >> Then I realised that other processes might not link against this malloc. > > Perhaps. > >> Then I realised the race condition doesn't even matter; processes will >> still be killed, as the kernel doesn't care that you're still in >> malloc() when the overcommitted memory is touched, it just knows you've >> touched it and there's no actual memory there. This will result in far >> more processes being killed. I believe that's a bad thing. > > Someone stated that it was a problem that malloc() returned pointers to virtual > address space that had been mapped but not allocated. This patch does not > guarantee that malloc() will return, but, if malloc() does returns a pointer, > using the memory being pointed to will refer to memory that is allocated. > > As Barny Wolff said: > > Won't this merely die in malloc, not return 0? > > True. This isn't a perfect solution, but given the choice between: > > 1) malloc(LOTS) returning a pointer, and then sometime later the program dies > with a bus error when using that memory because no more VM is available, or > > 2) malloc(LOTS) causing an immediate failure in malloc(), > > ...choice #2 appears to be significantly better. > > Figuring out what went wrong from a coredump or backtrace for #2 when the signal > happens in malloc() should be obvious; determining why the program crashed in > the middle of referencing memory in some large buffer is potentially misleading. > > Programs which take care to preallocate regions of memory they need before they > start doing a transaction or some other operation that needs to be atomic would > also prefer #2; the patch I proposed could have a beneficial impact on data > integrity for such programs. I believe that the problem isn't confined to dynamically allocated memory. I think it is also possible to run into problems when accessing a large static array, or even when not accessing memory at all if the kernel wants to free up some swap space and the process in question is sufficently large.