This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: address space leak in glibc 2.3.2?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]