[Bug libc/12129] New: mallop() M_MXFAST limit anomaly

["mtk.manpages at gmail dot com" <sourceware-bugzilla@sourceware.org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12129

           Summary: mallop() M_MXFAST limit anomaly
           Product: glibc
           Version: 2.12
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: mtk.manpages@gmail.com
                CC: wg@malloc.de


After the call mallopt(M_MXFAST, n), the user might expect that requests of up
to "n" bytes are allocated from fastbins. However, to ensure that requests of
size "n" are allocated from fastbins, it is necessary (on 32-bit) to make a
call of the form

malloc(M_MXFAST, ((n + 3) & ~7) + 4);

So, for example, to allocate blocks of size 29 bytes from fastbins, one must
make a mallopt() call where the argument is at least 36:

mallopt(M_MXFAST, 36);

The problem occurs because
1) When setting the M_MXFAST limit (set_max_fast()), the limit is rounded up
according to the formula:
(n + SIZE_SZ) & ~MALLOC_ALIGN_MASK)
2) The size required for malloc() allocations is rounded up according to the
formula:
(n + SIZE_SZ + MALLOC_ALIGN_MASK) & ~MALLOC_ALIGN_MASK

Possibly, the fix is as simple as redefining set_max_fast() as follows:

#define set_max_fast(s) \
  global_max_fast = (((s) == 0)        \
               ? SMALLBIN_WIDTH
               : ((s + SIZE_SZ - 1) & ~MALLOC_ALIGN_MASK) + SIZE_SZ)

However, I have not considered the implications of that change in detail.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.