address space leak in glibc 2.3.2?
Bruce Korb
bruce.korb@gmail.com
Thu Apr 10 20:15:00 GMT 2008
On Tue, Apr 8, 2008 at 2:50 PM, Bruce Korb <bruce.korb@gmail.com> wrote:
> Despite this being a development list,
Please pardon me for being treated like an idiot, but I do now have a theory
that explains the problem. I believe that this memory is an allocation arena:
> (gdb) x/64x 0x15e00000
> 0x15e00000: 0x15e00010 0x00000000 0x00021000 0x00000000
> 0x15e00010: 0x00000000 0x00000000 0x00000000 0x00000000
> 0x15e00020: 0x00000000 0x00000000 0x00000000 0x00000000
> 0x15e00030: 0x00000000 0x00000000 0x0000004a 0x00000000
> 0x15e00040: 0x00000000 0x00000000 0x00000000 0x00000000
> 0x15e00050: 0x00000000 0x15e004c8 0x00000000 0x00000000
> 0x15e00060: 0x00000000 0x15e00588 0x15e00590 0x00000000
> 0x15e00070: 0x00000000 0x15e0006c 0x15e0006c 0x15e00074
> 0x15e00080: 0x15e00074 0x15e0007c 0x15e0007c 0x15e00084
> 0x15e00090: 0x15e00084 0x15e0008c 0x15e0008c 0x15e00094
> 0x15e000a0: 0x15e00094 0x15e0009c 0x15e0009c 0x15e000a4
> 0x15e000b0: 0x15e000a4 0x15e000ac 0x15e000ac 0x15e000b4
> 0x15e000c0: 0x15e000b4 0x15e000bc 0x15e000bc 0x15e000c4
> 0x15e000d0: 0x15e000c4 0x15e000cc 0x15e000cc 0x15e000d4
> 0x15e000e0: 0x15e000d4 0x15e000dc 0x15e000dc 0x15e000e4
> 0x15e000f0: 0x15e000e4 0x15e000ec 0x15e000ec 0x15e000f4
I believe that these are allocated for every thread that calls malloc(). Given
that I have carefully documented that every malloc() is followed by the correct
free(), I am fairly convinced that these are lost arenas. That is,
its associated
thread has exited and there is no remaining allocated data in them.
So, my questions:
1. Does this look like an arena to you-all?
2. How do I determine if it is empty?
3. Has such a problem been addressed in a later glibc release?
4, Is there any mechanism for telling malloc to free up empty arenas?
(I *HAVE* looked at the docs, and if there is anything there, it has
not been made plain to me. There is something that alludes to getting
malloc to call sbrk with a negative value, but nothing for freeing arenas.)
5. This would also be solved with mallopt() calls, but they have no effect,
even when called within the __malloc_initialize_hook. Either one.
Perhaps "arenas" are not considered mmap-ped allocations?
Neither the documented disablement of mallopt(M_MMAP_MAX, 0);
nor what I was told is the real way: mallopt(M_MMAP_THRESHOLD, 0x100000);
(which is actually documented as not being guaranteed to work anyway.)
I chose not to use IRC simply because it is too difficult to compress this
into a one-line-at-a-time channel.
Thank you for your patience. Regards, Bruce
More information about the Libc-alpha
mailing list