proxyfmu process fails to terminate when running specific FMU

[ljamt]

Proxyfmu process fails to terminate (terminates after 2 min) when running the gunnerus-palfinger-crane case.
It seems to be the VesselFmu that causes this. It can be reproduced with the following configuration:

OspSystemStructure.xml:

<?xml version="1.0" encoding="utf-8"?>
<OspSystemStructure xmlns="http://opensimulationplatform.com/MSMI/OSPSystemStructure" version="0.1">
	<StartTime>0.0</StartTime>
	<BaseStepSize>1e-3</BaseStepSize>
	<Algorithm>fixedStep</Algorithm>
	<Simulators>
		<Simulator name="VesselFmu" source="proxyfmu://localhost?file=../fmus/VesselFmu.fmu" stepSize="0.05">
			<InitialValues>
				<InitialValue variable="vesselZipFile">
					<String value="absolute\path\to\ShipModel.zip"/>
				</InitialValue>
			</InitialValues>
		</Simulator>
	</Simulators>
</OspSystemStructure>

Using cosim-cli v0.5.0: cosim run \path\to\configuration\above\OspSystemStructure.xml -v the result is:

info: Using cache directory: "C:\\Users\\user\\AppData\\Local\\cosim"
[proxyfmu] Found proxyfmu executable: "proxyfmu.exe"
[proxyfmu] Booting FMU instance 'VesselFmu'..
[proxyfmu] FMU instance 'VesselFmu' instantiated using port 63248
info: 10% complete, t=0.100000
info: 20% complete, t=0.200000
info: 30% complete, t=0.300000
info: 40% complete, t=0.400000
info: 50% complete, t=0.500000
info: 60% complete, t=0.600000
info: 70% complete, t=0.700000
info: 80% complete, t=0.800000
info: 90% complete, t=0.900000
info: 100% complete, t=1.000000
<stuck here for 2 minutes>

Note 1 that this specific FMU requires vesselZipFile variable to be set to the absolute path of the ShipModel.zip as described here

Note 2 I've run the client test (test_controlled_temp) with the VesselFmu without any crash.

std::vector<value_ref> vr{2};
std::vector<std::string> stringVal{"C:\\dev\\osp\\demo-cases\\gunnerus-palfinger-crane\\fmus\\resources\\ShipModel.zip"};
slave->set_string(vr, stringVal);

[ljamt]

Running the gunnerus-palfinger-crane case with cosim-demo-app v0.7.0 using fmu-proxy, I see the exact same behavior for the vesselFmu. It never returns after freeing dlls. This issue should be moved to the demo-cases repo to fix the vesselFmu.