This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/12129] New: mallop() M_MXFAST limit anomaly
- From: "mtk.manpages at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Sun, 17 Oct 2010 14:33:31 +0000
- Subject: [Bug libc/12129] New: mallop() M_MXFAST limit anomaly
- Auto-submitted: auto-generated
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.