This is the mail archive of the
mailing list for the glibc project.
Re: thread heap leak?
On Mon, 29 Apr 2019 07:43:36 +0200
Florian Weimer <email@example.com> 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.