This is the mail archive of the
libc-alpha@sourceware.org
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: <20190322105304.1e848cefb45fb65d32a96b23@firstworks.com> <77992b67-3fdf-cad7-8ad8-0e27b9353791@redhat.com> <20190322133932.b5b9b2af28ec5941af810f21@firstworks.com> <6ff37227-4b52-25c5-d890-02b4becb2ae8@redhat.com> <20190325113758.73e9324a19727503d82d2d4c@firstworks.com> <20190330130635.c9e52acd94c8248c20709e92@firstworks.com> <c920f08b-85c6-6bd3-5ca4-7c9bebee3a99@redhat.com> <20190331231847.4e46776b2625e1d436607cbb@firstworks.com> <mvmh8biqgra.fsf@suse.de> <20190418093647.66b2e8b23c7817bbafa5dac1@firstworks.com> <87mukblrix.fsf@mid.deneb.enyo.de>
On Sat, 27 Apr 2019 11:35:34 +0200
Florian Weimer <fw@deneb.enyo.de> 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.
>
> Thanks,
> Florian
>
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.
Thanks,
David
david.muse@firstworks.com