This is the mail archive of the
mailing list for the glibc project.
Re: thread heap leak?
- From: David Muse <david dot muse at firstworks dot com>
- To: libc-alpha at sourceware dot org
- Cc: Florian Weimer <fw at deneb dot enyo dot de>, Andreas Schwab <schwab at suse dot de>, "Carlos O'Donell" <codonell at redhat dot com>
- Date: Sun, 28 Apr 2019 22:51:09 -0400
- Subject: Re: thread heap leak?
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
On Sat, 27 Apr 2019 11:35:34 +0200
Florian Weimer <email@example.com> wrote:
> * David Muse:
> > I can correlate call number 6 and calls numbered 10-27 with the
> > process map. Presumedly, 1-5 and 7-9 were unmapped. 10-27 appear to
> > be thread stacks, considering their size, and that they were called
> > with the MAP_STACK option :)
> The other regions appear to be 64 MiB heaps created by malloc, with
> some regions not backed by storage. There should be at least one such
> heap for each thread. They will be reused for new threads eventually.
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.