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?


Hi,

> 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
...

Looks like one..

> I believe that these are allocated for every thread that calls malloc().

No, they are allocated only for threads which _concurrently_ call malloc()
or related functions.  This way, malloc() is sure not to block on a
mutex.

Also note that there is a global arena list, so arenas are never "lost"
but re-used whenever possible.

> 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.

Yes, sure -- so their required size is approx. one page allocated
(for the linked list pointer) and some MB of reserved address space
(mapped PROT_NONE) so it can grow again as needed.

> So, my questions:
> 
> 1.  Does this look like an arena to you-all?

Yes.

> 2.  How do I determine if it is empty?

Please try malloc_stats().

> 3.  Has such a problem been addressed in a later glibc release?

What problem?  Yes there is max. one "dormant" arena (requiring 1 page
of memory and X MB reserved address space) for every thread that has
run _concurrently_ -- you should never have much more of those than
you have CPUs.  So I do not consider this a problem.

The same applies to thread stacks, which also take chunks of address
space.

I believe the example which you posted later created threads without
the "detached" attribute and did not pthread_join() them, so it might
actually have leaked thread stacks (pthreads w/o the detached
attribute can return a result, so at least this result has to be kept
indefinitely if no pthread_join() occurs).

> 4,  Is there any mechanism for telling malloc to free up empty arenas?

Sorry, no.  This could be added but in the light of the above I
see no need.

> 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?

Yes, they aren't.

E.g. thread stacks and AFAIK file buffers also are allocated with
mmap() so you would have a hard time avoiding mmap() altogether
on a threaded platform.

Regards,
Wolfram.


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