On Fri, Jan 04, 2008 at 01:25:45PM +0000, David Taylor wrote:
quoted text
> 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/
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"