FMI export Linux fmiFreeModelInstance

[joohnycz]

When I try to simulate FMU under Linux, the simulation is going well, but when I try to call fmiFreeModelInstance and then unload (dlclose) the FMU .so, it fails.

It seems that simulation depends on few .so from OpenModelica and when calling freeModelInstance are not dlclosed.

/usr/lib/lapack/liblapack.so.3.0
/usr/lib/libblas/libblas.so.3.0
/usr/lib/libsundials_kinsol.so.1.0.0
/usr/lib/omc/libcminpack.so.1.3.2
/usr/lib/omc/libcoinmumps.so.1.4.11
/usr/lib/omc/libgc.so.1.0.3
/usr/lib/omc/libipopt.so.1.9.6
/usr/lib/omc/liblis.so.0.0.0
/usr/lib/omc/libSimulationRuntimeC.so

Is it possible to unload libraries above when function fmiFreeModelInstance is called? I think it would agree with FMI standard ("Dispose the given model instance and deallocate all the allocated memory and other resources...").

And I guess that the simulation of FMU will fail on machine where OpenModelica is not installed - maybe I'll test it.

Ubuntu 14.04, OpenModelica 1.9.1+dev (r21649)

[Martin Sjölund]

OpenModelica never calls dlopen in the code as far as I know... so it will not be able to dlclose any of those files.
The only occurance of dlopen and FMUs in the OpenModelica code base seems to be in FMIL (libfmilib.so), but it is not used in exported FMUs.

And yes, you will most likely have OpenModelica installed in order to run the FMU since we do not include all shared objects in the FMU.

[Martin Sjölund]

Also, an interesting question: are you able to dlclose directly after calling dlopen?

[Adeel Asghar]

Replying to sjoelund.se:

OpenModelica never calls dlopen in the code as far as I know... so it will not be able to dlclose any of those files.
The only occurance of dlopen and FMUs in the OpenModelica code base seems to be in FMIL (libfmilib.so), but it is not used in exported FMUs.

And yes, you will most likely have OpenModelica installed in order to run the FMU since we do not include all shared objects in the FMU.

Martin he is talking about FMU export so FMIL has nothing to do with it.
We free most of the simulation data memory in fmiTerminate and few in fmiFreeModelInstance. Check both these functions in trunk/SimulationRuntime/fmi/export/fmi1/fmu1_model_interface.c

Martin can you test it with valgrind? I think the problem might be with the import he is using since FMUChecker doesn't complain about any such issues.

[Martin Sjölund]

From the way it is described, it is not our FMU Import (because it talks about manually calling dlclose, which is done automatically by the external objects).

Anyway gdb says there is 1 dlopen and 1 dlclose call when running export+import+simulate:

#0  __dlopen (
    file=0x61ce80 "/home/marsj/trunk/testsuite/openmodelica/fmi/ModelExchange/binaries/linux64/SampleEvent.so", mode=4098) at dlopen.c:75
#1  0x00007ffff797dc7f in fmi1_capi_load_dll (fmu=0x62fb90)
    at /home/marsj/trunk/3rdParty/FMIL/src/CAPI/src/FMI1/fmi1_capi.c:223
#2  0x00007ffff795fb8b in fmi1_import_create_dllfmu (fmu=0x631fc0, 
    callBackFunctions=..., registerGlobally=0)
    at /home/marsj/trunk/3rdParty/FMIL/src/Import/src/FMI1/fmi1_import_capi.c:88
    ...
    
    #0  __dlclose (handle=0x61a540) at dlclose.c:42
#1  0x00007ffff796a306 in jm_portability_free_dll_handle (dll_handle=0x61a540)
    at /home/marsj/trunk/3rdParty/FMIL/src/Util/src/JM/jm_portability.c:64
#2  0x00007ffff797bae4 in fmi1_capi_free_dll (fmu=<optimized out>, 
    fmu=<optimized out>)
    at /home/marsj/trunk/3rdParty/FMIL/src/CAPI/src/FMI1/fmi1_capi.c:254
#3  0x00007ffff795fd17 in fmi1_import_destroy_dllfmu (fmu=0x631dd0)
    at /home/marsj/trunk/3rdParty/FMIL/src/Import/src/FMI1/fmi1_import_capi.c:149
#4  0x00007ffff7bd72d8 in FMI1ModelExchangeDestructor_OMC (in_fmi1me=0x61d170)
    at fmi/FMI1ModelExchange.c:87
#5  0x00000000004064c1 in omc_SampleEvent__me__FMU_FMI1ModelExchange_destructor
    ()
#6  0x00000000004076ef in SampleEvent_me_FMU_callExternalObjectDestructors ()
#7  0x00007ffff7661ca4 in _main_SimulationRuntime (argc=<optimized out>, 
    argv=<optimized out>, data=0x7fffffffd480)
    at simulation/simulation_runtime.cpp:975
#8  0x000000000040627d in main ()

Valgrind says there are no memory errors except ~10kB of memory "lost" (it is free'd by the OS at process end).

[joohnycz]

Replying to sjoelund.se:

Also, an interesting question: are you able to dlclose directly after calling dlopen?

No, the behaviour is the same, dlclose is not successful.

I've been playing quite long time and calling

cat /proc/NNNN/maps | awk '{print $6}' | grep '\.so'

I found that libraries are really loaded at the time when I dlopen .so from OpenModelica (when I use FMU from other tool, those libraries are not loaded). I'm quite sure that my code doesn't access libraries in lib/omc/ folder (and because it shows only .so based on one PID, it can't be loaded by other apps).

I am using flags RTLD_NOW|RTLD_LOCAL for dlopen, can it cause the problem?

[Martin Sjölund]

Hmmm. It seems we open it with RTLD_NODELETE :) It is hard to know which of the dependent shared objects prevents you from closing the so-file though.

[Martin Sjölund]

Okay. I played around a little more with the following program:

#include <dlfcn.h>
#include <errno.h>
#include <stdio.h>
#include <string.h>

int main() {
    fprintf(stderr, "open...\n");
  void *p = dlopen("./SampleEvent.so",RTLD_NOW|RTLD_LOCAL|RTLD_NODELETE);
    fprintf(stderr, "opened... %p\n", p);
    fprintf(stderr, "dlerror: %s\n", dlerror());
  dlclose(p);
    fprintf(stderr, "closed...\n");
   {
    fprintf(stderr, "err: %s\n", strerror(errno));
  }
  return 1;
}

If I add RTLD_NODELETE, everything is fine. If it is not there, the program exits with code=0 and never returns from the dlclose call.

[Martin Sjölund]

r21774 should have fixed this.

[joohnycz <joohnycz@…>]

Works fine, thanks a lot.