Hi all,
there is a general problem with FMUs that employ OpenMP. Symptoms are:
compliance checker runs successfully through FMU compiled in debug mode with 0 warnings and 0 errors
when compliance checker runs with release-mode FMU, it stops silently after the last simulation output line
4.3200000000000000E+005,0.0000000000000000E+000,2.0000000000000000E+001,0.0000000000000000E+000
[INFO][FMUCHK] Simulation finished successfully at time 432000
> (command prompt appears)
Cause of the problem is a untrapped segfault. On both Visual Studio and gcc compilers, for performance reasons, the OpenMP threads spawned in parallel sections are kept for a few milliseconds after the parallel section was closed. This is to avoid the overhead of repeatedly opening/closing parallel sections. In debug mode, the delay of a few milliseconds between last parallel section and unloading/deleting FMU memory is sufficient. In release mode, the threads are still spinning while the master thread terminates and dll memory is freed. Thus, threads access the mutex/lock variable memory which has been freed already and segfault.
This problem should be adressed in the FMU itself by adding a sufficient delay past in the destructor of the FMU memory/dll unload function.
However, the compliance checker should still gracefully trap such a problem by raising a warning/error about crashes/segfaults during unloading/terminating of FMUs. When such an FMU is used in a simulation environment (i.e. Modelica simulator), it will may potentially crash the host application and thus cause data loss.
To analyse this problem, please see attached FMUs (remove the trailing zip extension first):
PipeCollectorModel_win64.fmu the original variant without explicit spin-down waiting
PipeCollectorModel_win64_waiting.fmu, variant with spin-down waiting
Note the console output of both FMUs at unloading of FMU.
Hi all, there is a general problem with FMUs that employ OpenMP. Symptoms are:
Cause of the problem is a untrapped segfault. On both Visual Studio and gcc compilers, for performance reasons, the OpenMP threads spawned in parallel sections are kept for a few milliseconds after the parallel section was closed. This is to avoid the overhead of repeatedly opening/closing parallel sections. In debug mode, the delay of a few milliseconds between last parallel section and unloading/deleting FMU memory is sufficient. In release mode, the threads are still spinning while the master thread terminates and dll memory is freed. Thus, threads access the mutex/lock variable memory which has been freed already and segfault.
This problem should be adressed in the FMU itself by adding a sufficient delay past in the destructor of the FMU memory/dll unload function.
However, the compliance checker should still gracefully trap such a problem by raising a warning/error about crashes/segfaults during unloading/terminating of FMUs. When such an FMU is used in a simulation environment (i.e. Modelica simulator), it will may potentially crash the host application and thus cause data loss.
To analyse this problem, please see attached FMUs (remove the trailing zip extension first):
Note the console output of both FMUs at unloading of FMU.
PipeCollectorModel_win64.fmu.zip PipeCollectorModel_win64_waiting.fmu.zip