Re: dlopen()/dlclose() and memory reclamation

[Sad Clouds <cryintothebluesky%googlemail.com@localhost>]

On Wed, 3 Nov 2010 15:01:30 +0100
Joerg Sonnenberger <joerg%britannica.bec.de@localhost> wrote:

> On Wed, Nov 03, 2010 at 09:35:26AM +0000, Sad Clouds wrote:
> > When application has finished with libA, it calls dlclose().
> > Assuming no other applications are using libA and libB, is memory
> > used by those libraries reclaimed, i.e. is it marked free for usage
> > by other processes, or does it permanently stay loaded in memory
> > for the duration of application?
> 
> What do you mean with "memory used by those libraries"? The dynamic
> linker will unmap the libraries after calling the destructor
> functions. It doesn't itself interacts with malloc in anyway.
> 
> Joerg

OK, what I mean is this:

As far as I understand, if an application is linked to a set of
shared libraries, those libraries are loaded on application's start up,
or whenever the application references symbols in those libraries. Once
loaded, they remain in memory until application exits.

What I'm trying to understand is how ld.so handles complex dependencies
when application calls dlopen() and then dlclose(). For example:

Application -> libA -> libB

Application calls dlopen() for libA, however libA depends on libB,
hence ld.so will automatically load libB. This way ld.so automatically
tracks dependencies when loading shared libraries.

The question I have is this: does ld.so track dependences the other way
round, i.e. when application calls dlclose(). For example, could you
tell me which one of the following occurs:

1. Application calls dlclose() on libA. If no other process is using
libA, ld.so unmaps libA, however libB remains loaded in memory.

or

2. Application calls dlclose() on libA. For each library that libA
depends on, ld.so recursively checks their dependencies and if no other
process is using each of those libraries, those libraries get unmapped.
Finally, ld.so unmaps libA.