Fatal JRE error - when co-sim on Mac

[richardpaynea55]

I have just downloaded and tried the new version of 20-sim (4.6.2-intocps) with the Line Follower Sensor to see if the issue with Mac co-simulation is still present. I successfully generated the FMU and ran the co-sim in Windows without issue. I then used the FMU builder in the INTO-CPS app as normal and have tried this newly compiled FMU in Mac. I now get a different error which appears to crash the COE. Screenshot below.

[margro]

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

[richardpaynea55]

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!

[lausdahl]

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

[richardpaynea55]

Zipped and attached.

hs_err_pid1175.log.zip

[lausdahl]

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

[lausdahl]

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

[richardpaynea55]

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

Using the lfr-non3d-rep multi-model.

[lausdahl]

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.