Date: Thu, 24 Jul 2003 16:51:16 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: cswiger@mac.com Cc: freebsd-stable@FreeBSD.org Subject: Re: malloc does not return null when out of memory Message-ID: <200307242351.h6ONpGM7055649@gw.catspoiler.org> In-Reply-To: <3F20692E.2060107@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200307242351.h6ONpGM7055649>