2
votes

I have made a shared library libA.so to load dynamically into a process using the dlopen(). libA.so has also linked to other shared libraries libB.so and libC.so. So when I load the libA.so using dlopen() the dependent shared libraries libB.so and libC.so are also loaded into the process.

I can see the libraries libA.so ,libB.so and libC.so loaded into the process using the command cat /proc/PID/maps

During the unload of the libA.so using the dlclose() the library libA.so is unloaded from the process.But the libraries libB.so and libC.so is not unloaded from the process.

From the cat /proc/PID/maps, I can see libA.so is unloaded but libB.so and libC.so still exits.

How can I unload the dependent shared libraries libB.so and libC.so from the process?

1
You can't. It's the kernel's job to reclaim that memory, not yours. - Sato Katsura
Seems like the seeds of an answer; "no" / "you can't" is a valid answer, IMHO. - Jeff Schaller

1 Answers

0
votes

How can I unload the dependent shared libraries libB.so and libC.so from the process?

You would need to first understand why these libraries are not unloaded when you dlclose libA.so.

There are a few possible reasons:

  1. One or both of the libraries may be marked with NODELETE flag.
  2. One or both of the libraries may have had their symbols used.

To check for #1, do this:

readelf -d libB.so libC.so | grep NODELETE

If this results in non-empty output, the dynamic loader has been told not to unload the library, and there is nothing you can do.

Checking for #2 is harder. One way #2 could happen is when e.g. libB.so initializer registers a function from libB.so with atexit. If the library was allowed to be unloaded, the function pointer that atexit has retained would become dangling, and calling exit would crash.

When using GLIBC, you could ask the loader to print symbol resolution info with LD_DEBUG=bindings ./a.out. This will produce lots of output, which should allow you to find out which symbols from e.g. libB.so are being bound. That may be sufficient to guess why libB.so doesn't get unloaded.