This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: thread heap leak?
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: David Muse <david dot muse at firstworks dot com>
- Cc: Andreas Schwab <schwab at suse dot de>, "Carlos O'Donell" <codonell at redhat dot com>, libc-alpha at sourceware dot org
- Date: Sat, 27 Apr 2019 11:35:34 +0200
- 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>
* 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