public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/12129] New: mallop() M_MXFAST limit anomaly
@ 2010-10-17 14:33 mtk.manpages at gmail dot com
2010-10-17 15:14 ` [Bug libc/12129] " drepper.fsp at gmail dot com
` (7 more replies)
0 siblings, 8 replies; 9+ messages in thread
From: mtk.manpages at gmail dot com @ 2010-10-17 14:33 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libc/12129] mallop() M_MXFAST limit anomaly
2010-10-17 14:33 [Bug libc/12129] New: mallop() M_MXFAST limit anomaly mtk.manpages at gmail dot com
@ 2010-10-17 15:14 ` drepper.fsp at gmail dot com
2010-10-24 7:56 ` [Bug libc/12129] mallopt() " mtk.manpages at gmail dot com
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: drepper.fsp at gmail dot com @ 2010-10-17 15:14 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libc/12129] mallopt() M_MXFAST limit anomaly
2010-10-17 14:33 [Bug libc/12129] New: mallop() M_MXFAST limit anomaly mtk.manpages at gmail dot com
2010-10-17 15:14 ` [Bug libc/12129] " drepper.fsp at gmail dot com
@ 2010-10-24 7:56 ` mtk.manpages at gmail dot com
2011-01-26 0:55 ` LpSolit at netscape dot net
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: mtk.manpages at gmail dot com @ 2010-10-24 7:56 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libc/12129] mallopt() M_MXFAST limit anomaly
2010-10-17 14:33 [Bug libc/12129] New: mallop() M_MXFAST limit anomaly mtk.manpages at gmail dot com
2010-10-17 15:14 ` [Bug libc/12129] " drepper.fsp at gmail dot com
2010-10-24 7:56 ` [Bug libc/12129] mallopt() " mtk.manpages at gmail dot com
@ 2011-01-26 0:55 ` LpSolit at netscape dot net
2012-03-29 4:39 ` mtk.manpages at gmail dot com
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: LpSolit at netscape dot net @ 2011-01-26 0:55 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libc/12129] mallopt() M_MXFAST limit anomaly
2010-10-17 14:33 [Bug libc/12129] New: mallop() M_MXFAST limit anomaly mtk.manpages at gmail dot com
` (2 preceding siblings ...)
2011-01-26 0:55 ` LpSolit at netscape dot net
@ 2012-03-29 4:39 ` mtk.manpages at gmail dot com
2013-03-17 17:31 ` carlos at redhat dot com
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: mtk.manpages at gmail dot com @ 2012-03-29 4:39 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libc/12129] mallopt() M_MXFAST limit anomaly
2010-10-17 14:33 [Bug libc/12129] New: mallop() M_MXFAST limit anomaly mtk.manpages at gmail dot com
` (3 preceding siblings ...)
2012-03-29 4:39 ` mtk.manpages at gmail dot com
@ 2013-03-17 17:31 ` carlos at redhat dot com
2013-04-15 9:35 ` [Bug malloc/12129] " siddhesh at redhat dot com
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: carlos at redhat dot com @ 2013-03-17 17:31 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug malloc/12129] mallopt() M_MXFAST limit anomaly
2010-10-17 14:33 [Bug libc/12129] New: mallop() M_MXFAST limit anomaly mtk.manpages at gmail dot com
` (4 preceding siblings ...)
2013-03-17 17:31 ` carlos at redhat dot com
@ 2013-04-15 9:35 ` siddhesh at redhat dot com
2014-06-30 7:48 ` fweimer at redhat dot com
2021-06-30 17:01 ` maxkamper at outlook dot com
7 siblings, 0 replies; 9+ messages in thread
From: siddhesh at redhat dot com @ 2013-04-15 9:35 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug malloc/12129] mallopt() M_MXFAST limit anomaly
2010-10-17 14:33 [Bug libc/12129] New: mallop() M_MXFAST limit anomaly mtk.manpages at gmail dot com
` (5 preceding siblings ...)
2013-04-15 9:35 ` [Bug malloc/12129] " siddhesh at redhat dot com
@ 2014-06-30 7:48 ` fweimer at redhat dot com
2021-06-30 17:01 ` maxkamper at outlook dot com
7 siblings, 0 replies; 9+ messages in thread
From: fweimer at redhat dot com @ 2014-06-30 7:48 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug malloc/12129] mallopt() M_MXFAST limit anomaly
2010-10-17 14:33 [Bug libc/12129] New: mallop() M_MXFAST limit anomaly mtk.manpages at gmail dot com
` (6 preceding siblings ...)
2014-06-30 7:48 ` fweimer at redhat dot com
@ 2021-06-30 17:01 ` maxkamper at outlook dot com
7 siblings, 0 replies; 9+ messages in thread
From: maxkamper at outlook dot com @ 2021-06-30 17:01 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-06-30 17:01 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-17 14:33 [Bug libc/12129] New: mallop() M_MXFAST limit anomaly mtk.manpages at gmail dot com
2010-10-17 15:14 ` [Bug libc/12129] " drepper.fsp at gmail dot com
2010-10-24 7:56 ` [Bug libc/12129] mallopt() " mtk.manpages at gmail dot com
2011-01-26 0:55 ` LpSolit at netscape dot net
2012-03-29 4:39 ` mtk.manpages at gmail dot com
2013-03-17 17:31 ` carlos at redhat dot com
2013-04-15 9:35 ` [Bug malloc/12129] " siddhesh at redhat dot com
2014-06-30 7:48 ` fweimer at redhat dot com
2021-06-30 17:01 ` maxkamper at outlook dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).