This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug malloc/20458] New: setting maximum arenas via mallopt ( M_ARENA_MAX ) is ineffective after a thread has been created
- From: "mcornish at ca dot ibm.com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 11 Aug 2016 13:27:16 +0000
- Subject: [Bug malloc/20458] New: setting maximum arenas via mallopt ( M_ARENA_MAX ) is ineffective after a thread has been created
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=20458
Bug ID: 20458
Summary: setting maximum arenas via mallopt ( M_ARENA_MAX ) is
ineffective after a thread has been created
Product: glibc
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: malloc
Assignee: unassigned at sourceware dot org
Reporter: mcornish at ca dot ibm.com
Target Milestone: ---
In arena_get2 , the arena limit will be imposed by static narenas_limit . It
is set the first time through (first time a thread is created and new arena
assigned) and won't be updated after that . If we have non-0 mp_.arena_max the
first time through (i.e. MALLOC_ARENA_MAX was set or mallopt ( M_ARENA_MAX, <n>
) was called before creating any threads), narenas_limit will be set to that
value. But after the first time through, mp_.arena_max will never be checked
again (to update narenas_limit), so mallopt ( M_ARENA_MAX, <n> ) will have no
effect.
Ideally the behavior would be fixed so that M_ARENA_MAX can be more dynamic.
It happened that our program inherited some infrastructure which makes it
difficult for us to customize malloc behavior before a few maintenance threads
are created.
Minimally documentation should be updated to state that mallopt ( M_ARENA_MAX,
<n> ) must be called before any threads are created, and it should fail
otherwise.
--
You are receiving this mail because:
You are on the CC list for the bug.