Probably fixed with: 242e5a6 by @lausdahl
Could you test with the latest template from Github?

from fmi-export-20sim.

I have just tested this. For the non-replicated version, the LFR example now works in Mac. The replicated version, however, does not. I've copied the error message below:

Terminal args: java -jar /Users/nrjp6/Library/Application Support/INTO-CPS APP/intoCpsApp/tmp/install_temp/coe.jar
Version: 0.2.2
Now running on port 8082
INFO [NanoHttpd Request Processor (#1)] (RequestProcessors.java:177) - Using Fixed-step size calculator with size = 0.01
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:44) - loading fmus
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:261) - Outputs from: {sensorFMU}.sensor2 = Set(lf_1_sensor_reading)
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:261) - Outputs from: {sensorFMU}.sensor1 = Set(lf_1_sensor_reading)
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:261) - Outputs from: {bodyFMU}.body = Set(robot_z, robot_theta, robot_y, total_energy_used, robot_x)
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:261) - Outputs from: {controllerFMU}.controller = Set(servoRightVal, servoLeftVal)
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:267) - Inputs for: {sensorFMU}.sensor1
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:269) - {bodyFMU}.body.robot_x --> robot_x
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:269) - {bodyFMU}.body.robot_y --> robot_y
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:269) - {bodyFMU}.body.robot_z --> robot_z
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:269) - {bodyFMU}.body.robot_theta --> robot_theta
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:267) - Inputs for: {sensorFMU}.sensor2
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:269) - {bodyFMU}.body.robot_x --> robot_x
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:269) - {bodyFMU}.body.robot_y --> robot_y
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:269) - {bodyFMU}.body.robot_z --> robot_z
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:269) - {bodyFMU}.body.robot_theta --> robot_theta
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:267) - Inputs for: {controllerFMU}.controller
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:269) - {bodyFMU}.body.total_energy_used --> total_energy_used
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:269) - {sensorFMU}.sensor1.lf_1_sensor_reading --> lfLeftVal
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:269) - {sensorFMU}.sensor2.lf_1_sensor_reading --> lfRightVal
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:267) - Inputs for: {bodyFMU}.body
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:269) - {controllerFMU}.controller.servoRightVal --> servo_right_input
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:269) - {controllerFMU}.controller.servoLeftVal --> servo_left_input
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:384) - Instantiating FMU. ModelName: 'Sensor_Block', GUID: '{74457c8c-7139-4739-b7df-1fe6f4b213c4}', Vendor tool: '', Generated by: '20-sim', at: Execution tool required: false
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:384) - Instantiating FMU. ModelName: 'Sensor_Block', GUID: '{74457c8c-7139-4739-b7df-1fe6f4b213c4}', Vendor tool: '', Generated by: '20-sim', at: Execution tool required: false
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:384) - Instantiating FMU. ModelName: 'Body_Block', GUID: '{d244d4b5-c549-4f26-afc4-7f8deef98023}', Vendor tool: '', Generated by: '20-sim', at: Execution tool required: false
INFO [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:384) - Instantiating FMU. ModelName: 'LFRController', GUID: '{f73d2d20-75a9-47f6-a701-03688afe5769}', Vendor tool: 'Overture', Generated by: 'Overture Tool FMI Exporter - v0.2.0', at: 2017-03-21T13:43:23 Execution tool required: true
WARN [NanoHttpd Request Processor (#1)] (CoeInitialize.scala:388) - Make sure the execution tool: 'Overture' is available during this simulation.

A fatal error has been detected by the Java Runtime Environment:

SIGSEGV (0xb) at pc=0x00000001154639ad, pid=1175, tid=4359

JRE version: Java(TM) SE Runtime Environment (8.0_51-b16) (build 1.8.0_51-b16)

Java VM: Java HotSpot(TM) 64-Bit Server VM (25.51-b03 mixed mode bsd-amd64 compressed oops)

Problematic frame:

C [Sensor_Block.dylib+0x49ad] findPosition+0x39

Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

An error report file with more information is saved as:

/Users/nrjp6/Library/Application Support/INTO-CPS APP/intoCpsApp/tmp/install_temp/coe-working-dir/hs_err_pid1175.log

If you would like to submit a bug report, please visit:

http://bugreport.java.com/bugreport/crash.jsp

The crash happened outside the Java Virtual Machine in native code.

See problematic frame for where to report the bug.

No alive signal from FMU withing 800 ms period. Freeing instance!
WARN [Thread-2] (ProtocolDriver.java:102) - No alive signal from FMU withing 800 ms period. Freeing instance!

from fmi-export-20sim.

please include the log its the file containing the lines that shows what is wrong

from fmi-export-20sim.

Zipped and attached.

hs_err_pid1175.log.zip

from fmi-export-20sim.

It looks like this fails as if the patch was not in. Are you sure you used HEAD and that you did not modify the file. If you do cat -e file you should se ^M$ for each line if the file is as expected with Windows encoding. That is the file in resources that it reads in.

stacktrace

Stack: [0x000070000b291000,0x000070000b391000],  sp=0x000070000b390040,  free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [Sensor_Block.dylib+0x49ad]  findPosition+0x39
C  [Sensor_Block.dylib+0x3eb4]  Table2D_TableRead+0x15f
C  [Sensor_Block.dylib+0x5ca2]  XXCalculateDynamic+0x719
C  [Sensor_Block.dylib+0x80d9]  XXInitializeSubmodel+0x5e
C  [Sensor_Block.dylib+0x362e]  fmi2ExitInitializationMode+0x20
C  [libfmuapi.dylib+0x34bd]  Java_org_intocps_fmi_jnifmuapi_NativeFmuComponent_nExitInitializationMode+0x41
j  org.intocps.fmi.jnifmuapi.NativeFmuComponent.nExitInitializationMode(JJ)B+0
j  org.intocps.fmi.jnifmuapi.FmuComponent.exitInitializationMode()Lorg/intocps/fmi/Fmi2Status;+13
j  org.intocps.orchestration.coe.BasicInitializer.initialize(Ljava/util/Map;Ljava/util/Map;Ljava/util/List;)Ljava/util/Map;+959
j  org.intocps.orchestration.coe.scala.CoeSimulator$.simulate(Lscala/collection/immutable/Map;Lscala/collection/immutable/Map;Lscala/collection/immutable/Map;DDLscala/collection/immutable/Map;Lorg/intocps/orchestration/coe/scala/Coe;)Lorg/intocps/orchestration/coe/scala/CoeObject$GlobalState;+56
j  org.intocps.orchestration.coe.scala.Coe.simulate(DDLjava/util/Map;ZD)V+251
j  org.intocps.orchestration.coe.httpserver.RequestProcessors.simulate(Ljava/lang/String;Ljava/lang/String;Z)Lfi/iki/elonen/NanoHTTPD$Response;+214
j  org.intocps.orchestration.coe.httpserver.RequestProcessors.processSimulate(Ljava/lang/String;Ljava/lang/String;Z)Lfi/iki/elonen/NanoHTTPD$Response;+4
j  org.intocps.orchestration.coe.httpserver.RequestHandler.simulate(Lfi/iki/elonen/NanoHTTPD$IHTTPSession;Ljava/lang/String;Z)Lfi/iki/elonen/NanoHTTPD$Response;+78
j  org.intocps.orchestration.coe.httpserver.RequestHandler.handleRequest(Lfi/iki/elonen/NanoHTTPD$IHTTPSession;)Lfi/iki/elonen/NanoHTTPD$Response;+120
j  org.intocps.orchestration.coe.httpserver.NanoWSDImpl.serveHttp(Lfi/iki/elonen/NanoHTTPD$IHTTPSession;)Lfi/iki/elonen/NanoHTTPD$Response;+69
j  fi.iki.elonen.NanoWSD.serve(Lfi/iki/elonen/NanoHTTPD$IHTTPSession;)Lfi/iki/elonen/NanoHTTPD$Response;+184
j  fi.iki.elonen.NanoHTTPD$HTTPSession.execute()V+496
j  fi.iki.elonen.NanoHTTPD$ClientHandler.run()V+59
j  java.lang.Thread.run()V+11
v  ~StubRoutines::call_stub
V  [libjvm.dylib+0x2e01e2]
V  [libjvm.dylib+0x2e0970]
V  [libjvm.dylib+0x2e0b1c]
V  [libjvm.dylib+0x33305d]
V  [libjvm.dylib+0x549a6f]
V  [libjvm.dylib+0x54b160]
V  [libjvm.dylib+0x46e99e]
C  [libsystem_pthread.dylib+0x39af]  _pthread_body+0xb4
C  [libsystem_pthread.dylib+0x38fb]  _pthread_body+0x0
C  [libsystem_pthread.dylib+0x3101]  thread_start+0xd
C  0x0000000000000000

from fmi-export-20sim.

Can you past the URL of the model and the commit id you are using so we can have a try as well.

from fmi-export-20sim.

URL: https://github.com/into-cps/case-study_line_follower_robot
Commit: 2fcf2f73eae2c34d0bf6e9aaf6d5ec2dbe770522

Using the lfr-non3d-rep multi-model.

from fmi-export-20sim.

Hi I can confirm that it doesnt work on Mac when cross compiled. However, there is no guarantee that it will work on any platform at best be behaviour is undefined for this issue.

Short version: Only use one instance.

Long version: The xxTable uses a global variable g_table2dFiles to store tables read from files (it does not track files) and a counter. This xxTable class is tailored to the 20sim model concerning the number of external Files it should be able to read. It is also suppose to return an error if this count exceeded the g_table2dFiles array size (renamed here to XXTABLE_FILE_COUNT)

#define XXTABLE_FILE_COUNT 1

/* Create a global variable to hold lookup tables */
LookupTable *g_table2dFiles[XXTABLE_FILE_COUNT];

the check in Table2D_Table2DInitlooks like this:

	/* is it possible to allocate more tables */
	if (g_table_count > XXTABLE_FILE_COUNT)
	{
		strncpy(g_lastError, "All tables already allocated", LASTERRMSGBUFSIZE);
		return 1;
	} 

this looks wrong to me because g_table_count represents an index and this is 0-based so either this should have been >= or > XXTABLE_FILE_COUNT-1.
Ok, but this is just the error that should have been shown when the second instance was made. The real issue is that the xxTable dont support dynamic allocation in the way it is used with FMI multiple instances. I see three ways to fix this:

1. Extend LookupTable to include the source or add something else so it can be detected where in the cache a certain datafile exists so it can be avoided that the file is read twice
2. Change the size of g_table2dFiles to XXTABLE_FILE_COUNT * FMI_ALLOWED_NUMBER_OF_INSTANCES
3. Allocate g_table2dFiles dynamically

I'm not able to fix this without knowing what CLP wants so I think it is best that @margro fixes this.

In the mean while just limit the usage to one instance of the FMU and it should work just fine.

from fmi-export-20sim.