[Bug malloc/20458] New: setting maximum arenas via mallopt ( M_ARENA_MAX ) is ineffective after a thread has been created

["mcornish at ca dot ibm.com" <sourceware-bugzilla at sourceware dot org>]

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.