Closed gi11 closed 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.
This problem should be solved. The glibc problem is caused by the Linux machine not having a recent enough version of the gnu libc.
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