INTO-CPS-Association / unifmu

A universal mechanism for implementing Functional Mock-up Units (FMUs) in various languages
41 stars 4 forks source link

FMU execution breaks after first call to freeInstance on Ubuntu vm #1

Closed gi11 closed 4 years ago

gi11 commented 4 years ago

Not sure if this should be two separate issues, but they might be connected for all I know

First, the libwrapper.so binary in the python_fmu example requires a version of libc (2.29) unavailable in ubuntu 18.04. I got the following error when trying to run the fmu in ubuntu 18.04:

/lib/x86_64-linux-gnu/libm.so.6: version 'GLIBC_2.29' not found (required by /home/user/Desktop/bac-co-simulation/into-cps-project/FMUs/python_fmu/binaries/linux64/libwrapper.so)

So, I rebuilt the wrapper and replaced the libwrapper.so binary with the one produced by running cargo build (libunifmu.so), and the error seemed to disappear - so far so good.

Afterwards, when running the python_fmu example in the INTO-CPS app or fmpy.gui, the simulation runs fine until freeInstance is called at the end of the simulation, and the following error is produced.

thread '<unnamed>' panicked at 'the sockets associated with the slave appears to be missing', src/lib.rs:298:9

After the first run, the simulation cant start again, unless the execution tool is restarted. If it is attempted to start the same simulation again, this one shows up

thread '<unnamed>' panicked at 'called 'Result::unwrap()' on an 'Err' value: "PoisonError { inner: .. }"', src/lib.rs:213:32

and then fmpy.gui crashes (maestro just aborts the simulation)

Restarting the execution tool solves the problem temporarily (until the next call to freeInstance), so my current workaround is just to restart the execution tool after each run, as the output/results from the first run seem fine

clegaard commented 4 years ago

The last error should be fixed now:

thread '<unnamed>' panicked at 'the sockets associated with the slave appears to be missing', src/lib.rs:298:9

This was due to the same socket being freed twice when a slave was freed.

clegaard commented 4 years ago

This problem should be solved. The glibc problem is caused by the Linux machine not having a recent enough version of the gnu libc.