Unload shared object (.so file) opened with dlopen() in C++

Question

The problem I'm facing is as follow:

I generate a shared object called customkinetics.so from a f90 file I use this object in a Cantera (chemistry code) written in C++ with a python interface. The object is called in a subroutine (CustomKinetics.cpp) as follow:

#include "cantera/kinetics/CustomKinetics.h"

#include <iostream>
#include <dlfcn.h>

using namespace std;

namespace Cantera 
{
  //Fortran External Routine
  extern "C"
  { 
    void customkinetics_(doublereal* P, doublereal* T, doublereal* rho, const doublereal* m_y, doublereal* wdot);
  }

  CustomKinetics::CustomKinetics(thermo_t* th) : GasKinetics(th)
  {
    printf("WARNING: Using customized kinetics from f90 file.\n");
    // Closing the library if it has already been opened
    if (handle == NULL){
        dlclose(handle);
    }
    handle = dlopen("customkinetics.so", RTLD_LAZY | RTLD_LOCAL);
    // load symbol
    ck = (ck_t) dlsym(handle, "customkinetics_");
  }

    void CustomKinetics::get_wdot_custom(doublereal* wdot)
  {

    doublereal P = thermo().pressure();
    doublereal T = thermo().temperature();
    doublereal rho = thermo().density();
    const doublereal* m_y = thermo().massFractions();

    // calculation
    ck(&P,&T,&rho,&m_y[0],&wdot[0]);
  }
}

It works fine until I overwrite the .f90 file that i then compile again thus overwriting the .so and then when I call it again I actually call the first object.

I know dlclose() is not supposed to completely remove the object from the memory but is there any way to do so ?

The fortran Makefile:

customkinetics.so: customkinetics.f90
    gfortran -c customkinetics.f90 -g -fPIC -o customkinetics.o
    gfortran -shared -o customkinetics.so customkinetics.o

Welcome. Please do not use the javascript snippet feature for other languages. Use the `{}` button. — Vladimir F Героям слава, Jun 15 '18 at 16:00
Could you check if [this answer](https://stackoverflow.com/a/50438832/2170527) is relevant? — yugr, Jun 15 '18 at 18:06
I checked and tried the answer but it doesn't seem to work in my case — Q.Cazères, Jun 17 '18 at 09:01

score 0 · Answer 1 · answered Jun 15 '18 at 17:28

I think it's better to understand why the dynamic shared object is still resident rather than attempt to force it to unload. dlclose() will unload the dynamic shared object from memory if the reference count on that object drops to zero. Are you sure the number of dlopen() and dlclose() calls in your code are the same?

It's also possible the reference count was implicitly incremented due to other dependencies. Can you confirm that nothing else depends your shared object?

On a related note, you're passing NULL to the dlclose() call in your constructor. Did you intend to check if the handle is not NULL, i.e.:

// Closing the library if it has already been opened
if (handle != NULL){
    dlclose(handle);
}

I'm sure that the number of {dlopen()} and {dlclose()} is the same. Nothing else depends on this shared library that I know of but there can be something hidden ... Yes, the last part is surely a mistake ! Is there any ways I can check what depends on this shared object and the count of that object ? I'm actually kinda new on C++ coding so I may miss things ... — Q.Cazères, Jun 17 '18 at 08:47

Unload shared object (.so file) opened with dlopen() in C++

1 Answers1