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.
The interface is what it is. Any change can only cause problems.
(In reply to comment #1) > The interface is what it is. Any change can only cause problems. This makes no sense. What possible problems can arise from a correct fix? This interface is purely about performance. A correct fix will only have the effect of changing the performance characteristics of some programs. Leaving this interface in the current broken state means that some programs will not obtain the performance improvement they expect from using the interface.
Reopening. As I noted in my last comment, the required fix affects only performance (i.e., users get the benefit they expect when they specify a particular M_MXFAST value), not the semantics of programs.
Just ran into an orthogonal issue surrounding M_MXFAST recently and found this open issue. I fully agree with Michael, it is wrong to document the interface one way and have the implementation behave in another way. I would accept and review patches to fix this. I would also accept a patch to add M_MXFAST which is mising from manual/memory.texi, and as a first step would accept documenting the current implementations behaviour (that way the canonical docs match the man pages).
I'm going to bump this ancient thread to ask why we don't just reinstate the use of request2size() in the set_max_fast() macro. That way Michael might finally rescue the 0xb0 fastbin from the clutches of Ulrich Drepper after 11 years.