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

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

[mtk.manpages at gmail dot com]

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.

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

[drepper.fsp at gmail dot com]

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

Ulrich Drepper <drepper.fsp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #1 from Ulrich Drepper <drepper.fsp at gmail dot com> 2010-10-17 15:14:49 UTC ---
The interface is what it is.  Any change can only cause problems.

-- 
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.

[Bug libc/12129] mallopt() M_MXFAST limit anomaly

[mtk.manpages at gmail dot com]

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

Michael Kerrisk <mtk.manpages at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|mallop() M_MXFAST limit     |mallopt() M_MXFAST limit
                   |anomaly                     |anomaly

--- Comment #2 from Michael Kerrisk <mtk.manpages at gmail dot com> 2010-10-24 05:26:31 UTC ---
(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.

-- 
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.

[Bug libc/12129] mallopt() M_MXFAST limit anomaly

[LpSolit at netscape dot net]

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

Michael Kerrisk <mtk.manpages at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|mallop() M_MXFAST limit     |mallopt() M_MXFAST limit
                   |anomaly                     |anomaly

--- Comment #2 from Michael Kerrisk <mtk.manpages at gmail dot com> 2010-10-24 05:26:31 UTC ---
(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.

-- 
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.

[Bug libc/12129] mallopt() M_MXFAST limit anomaly

[mtk.manpages at gmail dot com]

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

Michael Kerrisk <mtk.manpages at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |

--- Comment #3 from Michael Kerrisk <mtk.manpages at gmail dot com> 2012-03-28 23:34:44 UTC ---
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.

-- 
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.

[Bug libc/12129] mallopt() M_MXFAST limit anomaly

[carlos at redhat dot com]

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

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #4 from Carlos O'Donell <carlos at redhat dot com> 2013-03-17 17:31:09 UTC ---
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).

-- 
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.

[Bug malloc/12129] mallopt() M_MXFAST limit anomaly

[siddhesh at redhat dot com]

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

Siddhesh Poyarekar <siddhesh at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libc                        |malloc

-- 
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.

[Bug malloc/12129] mallopt() M_MXFAST limit anomaly

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug malloc/12129] mallopt() M_MXFAST limit anomaly

[maxkamper at outlook dot com]

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

Max <maxkamper at outlook dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maxkamper at outlook dot com

--- Comment #5 from Max <maxkamper at outlook dot com> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.