This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: thread heap leak?


David Muse <david.muse@firstworks.com> writes:
> Ahh, ok.  I have a couple of questions then...

Some of the answers are in the wiki:
https://sourceware.org/glibc/wiki/MallocInternals

> Is the 64MB segment size a result of my app doing 64MB of allocations,
> or is that a default heap size?  Is that tuneable?

Tunables are documented in the manual, or in manual/tunables.texi in the
source tree.  No tunables control the heap sizes, which are defined by
the two constants HEAP_MIN_SIZE (32kb) and HEAP_MAX_SIZE (1Mb for 32-bit
or 64Mb for 64-bit, IIRC)

> Is there a way to inspect the base address of a thread's heap from
> within the app?

As per the wiki, the base address of the heap is just the pointer,
masked to the right number of bits.  All heaps begin at a power of two.

> If a thread exits, is its heap marked as available?  If so, is this
> visible to the app?

I don't think any heap-specific information is available to the app.

> At what point do new threads recycle old heaps?  Eg. Does a newly
> created thread just grab a heap if an unused one is available, or is
> there a minimum number of old heaps that have to pile up before they
> will be recycled?  If there's a minimum number, is that tuneable?

First off, don't confuse heaps with arenas.  There are a fixed max
number of arenas, but each arena can have more than one heap as more
memory is required.  Heaps may be returned to the kernel if all their
memory is free'd, arenas are put on a free list when they're not used.
New threads prefer to attach to an arena on the free list, else a new
one is created if the max isn't reached, else arenas are shared.

> In a 64-bit app (on suse linux running on AWS (Xen)), should a
> malloc() crash when the address space grows to 2G?

No.

(technicality: malloc() should never *crash* anyway, but it may return
NULL and cause your application to crash ;)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]