Date: Fri, 4 Jan 2008 17:22:26 +0300 From: Andrey Chernov <ache@nagual.pp.ru> To: freebsd-current@FreeBSD.ORG Subject: Re: sbrk(2) broken Message-ID: <20080104142226.GA18773@nagual.pp.ru> In-Reply-To: <20080104132545.GA51075@outcold.yadt.co.uk> References: <20080104122149.GA17103@nagual.pp.ru> <5705.1199451431@critter.freebsd.dk> <20080104131247.GA17816@nagual.pp.ru> <20080104132545.GA51075@outcold.yadt.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 04, 2008 at 01:25:45PM +0000, David Taylor wrote: > On Fri, 04 Jan 2008, Andrey Chernov wrote: > > > On Fri, Jan 04, 2008 at 12:57:11PM +0000, Poul-Henning Kamp wrote: > > > There is address space allocated to the process (via sbrk/mmap) > > > > > > A subset of this, is address space allocated by the program (via malloc) > > > > > > ...and then there is memory actually in use, which is an entirely different > > > thing, of which we currently only have some kind of clue in the VM > > > system. > > > > Then, we need sysctl to fetch that "memory actually in use" from the > > kernel and compare that with getrlimit() which allows malloc() to return > > 0 when needed. > > That won't help much -- malloc could have allocated some address space that > hasn't (yet) been touched by the process. Just returning 0 when the > amount of memory "in use" hits a limit wouldn't stop the process from > then touching all the memory it has previously been allocated and > exceeding the limit. In that case the process is subject to be killed by system, if exceeds its limits. But... this is not malloc() problem at all, malloc() designed to detect overflow situation, not prevent it. The malloc() problem is not returning 0. -- http://ache.pp.ru/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080104142226.GA18773>