RTWSFCN FMU crashes on fmi2Reset()

[dirk-runge]

Hi,

I'm using FMI Toolkit version 2.4. In general it works well but I get reproducible crashes when calling fmi2Reset. Sometimes the fmi2Reset function crashes directly, sometimes the following call to fmi2DoStep crashes.

I downloaded & built today's Master-Branch (23.05.19) and compiled the FMU with that version. Still the same problem.

I'm compiling a FMI2, CoSimulation FMU on win64.

I'm working on my own Co-Simulation master and I'm not ruling out the possibility that there is a bug in my code. However, I think that's rather unlikely because FMUs generated by other tools work well.

Unfortunately my use-case requires the reset to work, so I would appreciate if you could take at looks at this. If you could explain how I can generate the .dll with debug information included, I might be able to track down the problem for you.

Best Regards
Dirk

[t-sommer]

I'm using FMI Toolkit version 2.4. In general it works well but I get reproducible crashes when calling fmi2Reset. Sometimes the fmi2Reset function crashes directly, sometimes the following call to fmi2DoStep crashes.

Can you provide steps to reproduce the problem (MATLAB version, exported model, solver settings, target)?

I downloaded & built today's Master-Branch (23.05.19) and compiled the FMU with that version. Still the same problem.

To get the latest development version you should use the develop branch. Master gets only updated on releases.

If you could explain how I can generate the .dll with debug information included, I might be able to track down the problem for you.

Creating a debug version is easy. grtfmi.tlc creates a Visual Studio solution in the build folder (modelname_grt_fmi_rtw). Building the project in debug mode yields an FMU with a debug DLL in the build folder.
For the rtwsfcnfmi.tlc target you can use the included rtwsfcnfmi/CMakeLists.txt to create a Visual Studio solution from the generated source code.

[dirk-runge]

Thanks for your answer Torsten.

I was able to build a debug-DLL by generating a Visual Studio solution with grtfmi.tlc and then building the debug configuration. However, the debug-DLL does not support the fmi2Reset function at all. If I step into the fmi2Reset call with the Visual Studio debugger I end up in fmi2Functions.c line 89, where a constant fmi2Error is returned.

The rtwsfcnfmi.tlc seems to use the fmi2Reset implementation in fmi2.c line 462 instead. My rtwsfcnfmi.tlc-generated FMU still crashes with the development-version. I didn't fully understand how I can build a debug-version for rtwsfcnfmi.tlc. Are you saying it's enough to build the Debug version instead of the Release version (i.e. changing DCMAKE_BUILD_TYPE=Release to DCMAKE_BUILD_TYPE=Debug in build.bat)? I could do that but isn't the build-process in Matlab still using compiler optimization flags?

We exported many different models as FMUs that use different solvers, step-sizes etc. They all crash. However, I created a "minimal test" model that uses a fixed step ode3 solver with step size 1e-3. We use both R2015b and R2017b to generate FMUs (both crash).

Usually it takes multiple calls to fmi2Reset before the crash happens. Yesterday it always took exactly 2037 calls to fmi2Reset until the crash happened. In the end it crashes because it de-references a NULL-Pointer. Of course it's hard to predict what will happen if there is a bad pointer...

As I said in general the FMU works well. I run through the usual initialization stuff like fmi2SetupExperiment, fmi2EnterInitalizationMode, fmi2ExitInitializationMode. After that it just does a Loop of fmi2SetXXX for the inputs, fmi2DoStep, fmi2GetXXX for the outputs. Now, when my application wants to reset the model, it calls fmi2Reset and then runs through the initialization again (fmi2SetupExperiment....) and it will then crash on the call to fmi2DoStep.

[dirk-runge]

I found out that the crash is related to the calls to
rt_DestroyIntegrationData(model->S);
rt_CreateIntegrationData(model->S);
in fmi2Reset.

If I comment these two lines it doesn't crash anymore.

[APillekeit]

I made the same observation: FMU exported with grtfmi.tlc and FMI Kit 2.6 crashes at fmi2Reset() due to illegal memory access.

[t-sommer]

@APillekeit, can you reproduce the problem with the latest version grtfmi.tlc on develop?

[patengel]

I came across the same issue and have a proposal how to fix it.
It would be nice if you have a short look at the proposal.

[t-sommer]

It would be nice if you have a short look at the proposal.

@patengel, please open a new issue and provide steps to reproduce the problem with the latest release.

[APillekeit]

Hi,

I'm sorry I cannot look into this because I don't have access to Simulink anymore.

My old issue was already solved and the code was integrated in the new release. Thanks again for that!

My recommendation for a workaround would be to avoid the use of fmi2Reset() - if possible - and to reinstantiate the model via fmi2FreeInstance() and fmi2Instantiate(). In my oppinion this is safer anyhow because it also safely resets hidden variables/states of badly written code inside of the FMU model (e.g. in s-functions).

[t-sommer]

@Krid82, @APillekeit, can you give d2acf28 497993f a try?