Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fatal JRE error - when co-sim on Mac #20

Closed
richardpaynea55 opened this issue Sep 20, 2016 · 8 comments
Closed

Fatal JRE error - when co-sim on Mac #20

richardpaynea55 opened this issue Sep 20, 2016 · 8 comments
Assignees
Labels

Comments

@richardpaynea55
Copy link

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.

screenshot 2016-09-19 17 27 45

@margro
Copy link
Member

margro commented Mar 28, 2017

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

@margro margro closed this as completed Mar 28, 2017
@richardpaynea55
Copy link
Author

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
Copy link
Contributor

lausdahl commented Apr 3, 2017

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

@richardpaynea55
Copy link
Author

Zipped and attached.

hs_err_pid1175.log.zip

@lausdahl
Copy link
Contributor

lausdahl commented Apr 3, 2017

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
Copy link
Contributor

lausdahl commented Apr 3, 2017

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

@richardpaynea55
Copy link
Author

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

Using the lfr-non3d-rep multi-model.

@lausdahl
Copy link
Contributor

lausdahl commented Apr 4, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants