Re: thread heap leak?

[David Muse <david dot muse at firstworks dot com>]

On Mon, 29 Apr 2019 07:43:36 +0200
Florian Weimer <fw@deneb.enyo.de> wrote:

> * David Muse:
> 
> > Is there a case where they wouldn't be reused, or where the VIRT might
> > grow to 2G or more before they are?  I think that's what I'm seeing.
> > Those heaps pile up until the VIRT is about 2G, then the app crashes.
> 
> If you create 32 threads which make some long-term allocations and
> then exit, without creating new threads, there will be 32 such heaps,
> occupying 2 GiB of address space.  They will only get reused if you
> create new threads.
> 

Ahh, ok.  I have a couple of questions then...

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

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

If a thread exits, is its heap marked as available?  If so, is this visible 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?

In a 64-bit app (on suse linux running on AWS (Xen)), should a malloc() crash when the address space grows to 2G?  I ask because my app was originally compiled as a 32-bit app, and we noticed that a malloc() would crash when the address space grew to 2G.  This made sense, but we recompiled it as a 64-bit app and still see the same behavior.

Thanks!

David
david.muse@firstworks.com