theoretically question: is dlopen() loading a update lib or send back the old handler?

Carlos O'Donell
Sun Nov 29 15:00:00 GMT 2015

On 11/29/2015 09:07 AM, Michael Eager wrote:
> If you modify the library, the old version of the library
> will remain in use until all uses of the library close it.
> Program B, loaded after the library was modified, will
> see the old version of the library.

I think a more precise answer would be like this:

If process A, loading program A, has loaded (mmap completed)
library X at version M *before* the library X changed to version N, 
then process A dlopen always returns a handle to library X at version
M as long as process A does not close that handle, and such a close
results in a library unload (unmap). If the library is unmapped then
subsequent dlopen's which happen *after* the filesystem change of
library X to version N (not M), then the implementation is free to
load the new library X at version N.

If process B, loading program B, has loaded (mmap completed)
library X at version N *after* the library changed, then process A
dlopen always returns a handle to that new library.

The key point is that even if you delete the file on the filesystem,
the kernel maintains a copy of library X at version M for use by process
A's mmap. There is a held reference count on that file. In fact if you
have enough long running processes and have upgraded enough times, there
could be significant files which are deleted but not removed given the
reference counts are not zero. The only way to get back that free space
is to restart those processes using the old copies of the files.

In summary: You will never have a shared library yanked out from under
you during a system upgrade as long as you have the library already loaded.

This says nothing about groups of libraries. Since there is no atomic way
to load multiple libraries.


More information about the Libc-help mailing list