Re: RLIMIT_DATA and malloc(3) use of mmap(2)

From: Kostik Belousov <kostikbel_at_gmail.com>
Date: Thu, 24 Nov 2011 22:29:45 +0200
On Thu, Nov 24, 2011 at 09:38:19PM +0400, Maxim Konovalov wrote:
> Hi Kostik,
> 
> On Wed, 23 Nov 2011, 11:22+0400, Maxim Konovalov wrote:
> 
> > [...]
> > > Anyway, the patch needs testers before I will push it forward.
> > >
> > [igor's email was corrected]
> >
> > We will test it in out environment and let you know.
> >
> It seems I don't understand how it works.
> 
> Here is a test program: http://maxim.int.ru/stuff/malloc_test.c.txt
> 
> It allocates successfully 64x1MB chunks by malloc(), reallocf() and
> realloc() with the following command line:
> 
> MALLOC_OPTIONS=JM limits -d 10m ./malloc_test
> 
> When we add L flag to the MALLOC_OPTIONS it starts to work strange:
> 
> It allocates 64MB via malloc() but fails to allocate more than 3MB by
> realloc() and reallocf().
The non-failing 64MB allocation is easily explained by a bug.
I forgot to account for the case when existing map entry was expanded,
instead of new entry created due to mmap(2).

The other part, in particular, the failure after 3MB, is in fact the
correct behaviour. Jemalloc() caches allocation of the pages, and it
allocates more then asked in the request. ktrace(1) shows the whole
history.

Malloc() first allocated 4MB for the needs of libc etc. Then, it allocated
4MB chunk which was used for satisfying the requests of 1-3MB. When the
4MB request came in, the allocation for 8MB was attempted, and failed,
since 4MB (libc etc) + 8MB = 12MB > data limit.
> 
> More funny, the result varies from time to time:
I have no explanation for this, and cannot reproduce the issue.
Look at the ktrace.

Overall, the test is quite curious but absolutely unrealistic.
Fixed patch is available at
http://people.freebsd.org/~kib/misc/map_datalimit.2.patch

Received on Thu Nov 24 2011 - 19:29:50 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:21 UTC