Date: Fri, 25 Jul 2003 07:37:07 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: "Steve O'Hara-Smith" <steve@sohara.org> Cc: freebsd-stable@freebsd.org Subject: Re: malloc does not return null when out of memory Message-ID: <20030724213707.GU430@gsmx07.alcatel.com.au> In-Reply-To: <20030724201702.6667b707.steve@sohara.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> <20030724201702.6667b707.steve@sohara.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2003-Jul-24 20:17:02 +0200, Steve O'Hara-Smith <steve@sohara.org> wrote:
>On Thu, 24 Jul 2003 12:45:22 -0400
>Barney Wolff <barney@databus.com> wrote:
>
>BW> On Thu, Jul 24, 2003 at 11:15:43AM -0400, Chuck Swiger wrote:
>BW> >
>BW> > +/* write a single byte per page to disable overcommit behavior */
>BW> > +static int malloc_overcommit;
>BW>
>BW> Won't this merely die in malloc, not return 0?
>
> Yes - it needs to trap the SEGV as well to produce the wanted
>behaviour, something like:
...
> Where ocsighandleron() installs a SEGV handler that sets ocsignalled
>when called and ocsighandleroff() installs the original one.
This still can't handle all cases. Handling the SEGV may require
additional memory - particularly stack - which isn't available.
You also need to free() the memory before returning NULL. This
may allow a future smaller malloc to succeed.
I'd suggest adding code in the "malloc_overcommit" path to touch stack
that is likely to be used, close to the top of {m,c,re}alloc().
There's a gcc-specific extension "__builtin_frame_address()" that will
let you do this. This ensures that the stack pages you need are
present before you try to sbrk() the data. There may still be other
corner cases I've missed.
Cleanly recovering in all cases when there is no additional memory
available is a very hard problem. Most of the suggested fixes
generally rely on the kernel providing a warning when the VM system
is under stress but can still satisfy some requests. Unfortunately,
I don't think any of them included the necessary patches.
I think the idea of adding entries to both the FAQ and malloc(3)
explaining what happens is good. The text that was posted is
probably "good-enough" for a start - all that's needed is a decent
URL to provide a more detailed explanation to replace the '****'.
Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030724213707.GU430>