Date: Thu, 2 Dec 2010 13:14:20 -0800 From: Artem Belevich <fbsdlist@src.cx> To: Andrew Duane <aduane@juniper.net> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Question about process rlimits Message-ID: <AANLkTi=g_wCn2UK8afB0srfM%2B_y8gNLCKQKDRxrNUdSg@mail.gmail.com> In-Reply-To: <AC6674AB7BC78549BB231821ABF7A9AE907A1E0703@EMBX01-WF.jnpr.net> References: <AC6674AB7BC78549BB231821ABF7A9AE907A1E0703@EMBX01-WF.jnpr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Thu, Dec 2, 2010 at 12:51 PM, Andrew Duane <aduane@juniper.net> wrote: > > I've been poking at some bugs we have around pushing user memory to/past the limits of our box, and decided to try seeing what happens on a stock FreeBSD system (7.1 in this case). > > Basically I have a program that mallocs big memory chunks and zeros them to consume both physical and virtual memory. I had expected the program to stop malloc'ing when brk() reaches the process' RLIMIT_DATA (512MB cur and max). It didn't. It happily malloc'd many gigabytes of memory until I stopped it. > > On our 6.2 based product boxes, RLIMIT_DATA correctly stops the malloc from continuing, just like the manuals say. > > Am I missing something? Perhaps that malloc has two ways of grabbing memory from system -- sbrk() and mmap() and they are subject to different limits. I believe these days malloc is allowed to use both but prefers mmap which would explain why RLIMIT_DATA didn't have much effect. Try forcing malloc to use sbrk only via MALLOC_OPTIONS=Dm (not sure if that's correct way to specify my intent, though). --Artem
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=g_wCn2UK8afB0srfM%2B_y8gNLCKQKDRxrNUdSg>