Closed bergtwvd closed 5 years ago
Program was missing tests for null pointer after a map.get() call. Have added such tests in the program for this problem.
I reran the test with the latest build; still some stracktraces:
tc-runner_1 | 2018-12-14 19:31:50,706 de.fraunhofer.iosb.tc_encodingrulestester.TC0001:
tc-runner_1 | Object name: EmitterVRFFederateHandle<2>:13 Known object class: HLAobjectRoot.EmbeddedSystem.EmitterSystem Attribute name: EventIdentifier
tc-runner_1 | Object handle: instance<112> Attribute handle: attribute<283>
tc-runner_1 | Attribute value bytes: 000000
tc-runner_1 | 2018-12-14 19:31:50,707 de.fraunhofer.iosb.tc_encodingrulestester.TC0001: HlaDataFixedRecordType: testBuffer: current position: 0 calculated total buffer l
ength : 2 cannot get data type: RTIobjectId
tc-runner_1 | hla.rti1516e.exceptions.FederateInternalError
tc-runner_1 | at se.pitch.prti1516e.lrc.t.a(prticore_b2920:37)
tc-runner_1 | at se.pitch.prti1516e.lrc.t.reflectAttributeValues(prticore_b2920:1013)
tc-runner_1 | at se.pitch.prti1516e.lrc.MsgReflectAttributeValues.a(prticore_b2920:91)
tc-runner_1 | at se.pitch.prti1516e.lrc.MyFederate.a(prticore_b2920:6221)
tc-runner_1 | at se.pitch.prti1516e.lrc.TimeStateIdle.a(prticore_b2920:52)
tc-runner_1 | at se.pitch.prti1516e.lrc.MyFederate.bE(prticore_b2920:6467)
tc-runner_1 | at se.pitch.prti1516e.lrc.MyFederate.e(prticore_b2920:6421)
tc-runner_1 | at se.pitch.prti1516e.lrc.MyFederate.aT(prticore_b2920:6342)
tc-runner_1 | at se.pitch.prti1516e.lrc.y.run(prticore_b2920:91)
tc-runner_1 | at java.lang.Thread.run(Thread.java:745)
tc-runner_1 | Caused by: java.lang.NullPointerException
tc-runner_1 | at de.fraunhofer.iosb.tc_lib_encodingrulestester.HlaDataFixedRecordType.testBuffer(HlaDataFixedRecordType.java:143)
tc-runner_1 | at de.fraunhofer.iosb.tc_lib_encodingrulestester.EncodingRulesTesterBaseModel.doReflectAttributeValues(EncodingRulesTesterBaseModel.java:986)
tc-runner_1 | at de.fraunhofer.iosb.tc_lib_encodingrulestester.EncodingRulesTesterBaseModel.reflectAttributeValues(EncodingRulesTesterBaseModel.java:1020)
tc-runner_1 | at de.fraunhofer.iosb.tc_lib.IVCT_LoggingFederateAmbassador.reflectAttributeValues(IVCT_LoggingFederateAmbassador.java:550)
tc-runner_1 | at se.pitch.prti1516e.lrc.t.reflectAttributeValues(prticore_b2920:1006)
tc-runner_1 | ... 8 more
tc-runner_1 | 2018-12-14 19:31:50,716 de.fraunhofer.iosb.tc_encodingrulestester.TC0001:
tc-runner_1 | Object name: EmitterVRFFederateHandle<2>:2 Known object class: HLAobjectRoot.EmbeddedSystem.EmitterSystem Attribute name: EmitterIndex
tc-runner_1 | Object handle: instance<122> Attribute handle: attribute<282>
tc-runner_1 | Attribute value bytes: 01
tc-runner_1 | 2018-12-14 19:31:50,717 de.fraunhofer.iosb.tc_encodingrulestester.TC0001: TEST BUFFER CORRECT
tc-runner_1 | 2018-12-14 19:31:52,078 de.fraunhofer.iosb.tc_encodingrulestester.TC0001:
tc-runner_1 | Object name: VRFFederateHandle<2>:52 Known object class: HLAobjectRoot.BaseEntity.PhysicalEntity.Platform.SurfaceVessel Attribute name: IsPartOf
tc-runner_1 | Object handle: instance<101> Attribute handle: attribute<146>
tc-runner_1 | Attribute value bytes: 000000000000000000000000000000000000000000000000
tc-runner_1 | 2018-12-14 19:31:52,079 de.fraunhofer.iosb.tc_encodingrulestester.TC0001: HlaDataFixedRecordType: testBuffer: current position: 0 calculated total buffer l
ength : 6 cannot get data type: RTIobjectId
tc-runner_1 | hla.rti1516e.exceptions.FederateInternalError
tc-runner_1 | at se.pitch.prti1516e.lrc.t.a(prticore_b2920:37)
tc-runner_1 | at se.pitch.prti1516e.lrc.t.reflectAttributeValues(prticore_b2920:1013)
tc-runner_1 | at se.pitch.prti1516e.lrc.MsgReflectAttributeValues.a(prticore_b2920:91)
tc-runner_1 | at se.pitch.prti1516e.lrc.MyFederate.a(prticore_b2920:6221)
tc-runner_1 | at se.pitch.prti1516e.lrc.TimeStateIdle.a(prticore_b2920:52)
tc-runner_1 | at se.pitch.prti1516e.lrc.MyFederate.bE(prticore_b2920:6467)
tc-runner_1 | at se.pitch.prti1516e.lrc.MyFederate.e(prticore_b2920:6421)
tc-runner_1 | at se.pitch.prti1516e.lrc.MyFederate.aT(prticore_b2920:6342)
tc-runner_1 | at se.pitch.prti1516e.lrc.y.run(prticore_b2920:91)
tc-runner_1 | at java.lang.Thread.run(Thread.java:745)
tc-runner_1 | Caused by: java.lang.NullPointerException
tc-runner_1 | at de.fraunhofer.iosb.tc_lib_encodingrulestester.HlaDataFixedRecordType.testBuffer(HlaDataFixedRecordType.java:143)
tc-runner_1 | at de.fraunhofer.iosb.tc_lib_encodingrulestester.EncodingRulesTesterBaseModel.doReflectAttributeValues(EncodingRulesTesterBaseModel.java:986)
tc-runner_1 | at de.fraunhofer.iosb.tc_lib_encodingrulestester.EncodingRulesTesterBaseModel.reflectAttributeValues(EncodingRulesTesterBaseModel.java:1020)
tc-runner_1 | at de.fraunhofer.iosb.tc_lib.IVCT_LoggingFederateAmbassador.reflectAttributeValues(IVCT_LoggingFederateAmbassador.java:550)
tc-runner_1 | at se.pitch.prti1516e.lrc.t.reflectAttributeValues(prticore_b2920:1006)
tc-runner_1 | ... 8 more
tc-runner_1 | hla.rti1516e.exceptions.FederateInternalError
tc-runner_1 | at se.pitch.prti1516e.lrc.t.a(prticore_b2920:37)
tc-runner_1 | at se.pitch.prti1516e.lrc.t.reflectAttributeValues(prticore_b2920:1013)
tc-runner_1 | at se.pitch.prti1516e.lrc.MsgReflectAttributeValues.a(prticore_b2920:91)
tc-runner_1 | at se.pitch.prti1516e.lrc.MyFederate.a(prticore_b2920:6221)
tc-runner_1 | at se.pitch.prti1516e.lrc.TimeStateIdle.a(prticore_b2920:52)
tc-runner_1 | at se.pitch.prti1516e.lrc.MyFederate.bE(prticore_b2920:6467)
tc-runner_1 | at se.pitch.prti1516e.lrc.MyFederate.e(prticore_b2920:6421)
tc-runner_1 | at se.pitch.prti1516e.lrc.MyFederate.aT(prticore_b2920:6342)
tc-runner_1 | at se.pitch.prti1516e.lrc.y.run(prticore_b2920:91)
tc-runner_1 | at java.lang.Thread.run(Thread.java:745)
tc-runner_1 | Caused by: java.lang.NullPointerException
tc-runner_1 | at de.fraunhofer.iosb.tc_lib_encodingrulestester.HlaDataFixedRecordType.testBuffer(HlaDataFixedRecordType.java:143)
tc-runner_1 | at de.fraunhofer.iosb.tc_lib_encodingrulestester.EncodingRulesTesterBaseModel.doReflectAttributeValues(EncodingRulesTesterBaseModel.java:986)
tc-runner_1 | at de.fraunhofer.iosb.tc_lib_encodingrulestester.EncodingRulesTesterBaseModel.reflectAttributeValues(EncodingRulesTesterBaseModel.java:1020)
tc-runner_1 | at de.fraunhofer.iosb.tc_lib.IVCT_LoggingFederateAmbassador.reflectAttributeValues(IVCT_LoggingFederateAmbassador.java:550)
tc-runner_1 | at se.pitch.prti1516e.lrc.t.reflectAttributeValues(prticore_b2920:1006)
tc-runner_1 | ... 8 more
tc-runner_1 | 2018-12-14 19:31:52,159 de.fraunhofer.iosb.tc_encodingrulestester.TC0001:
tc-runner_1 | Object name: VRFFederateHandle<2>:1 Known object class: HLAobjectRoot.BaseEntity.PhysicalEntity.Platform.SurfaceVessel Attribute name: IsPartOf
tc-runner_1 | Object handle: instance<102> Attribute handle: attribute<146>
tc-runner_1 | Attribute value bytes: 000000000000000000000000000000000000000000000000
tc-runner_1 | 2018-12-14 19:31:52,161 de.fraunhofer.iosb.tc_encodingrulestester.TC0001: HlaDataFixedRecordType: testBuffer: current position: 0 calculated total buffer l
ength : 6 cannot get data type: RTIobjectId
tc-runner_1 | hla.rti1516e.exceptions.FederateInternalError
tc-runner_1 | at se.pitch.prti1516e.lrc.t.a(prticore_b2920:37)
tc-runner_1 | at se.pitch.prti1516e.lrc.t.reflectAttributeValues(prticore_b2920:1013)
tc-runner_1 | at se.pitch.prti1516e.lrc.MsgReflectAttributeValues.a(prticore_b2920:91)
tc-runner_1 | at se.pitch.prti1516e.lrc.MyFederate.a(prticore_b2920:6221)
tc-runner_1 | at se.pitch.prti1516e.lrc.TimeStateIdle.a(prticore_b2920:52)
tc-runner_1 | at se.pitch.prti1516e.lrc.MyFederate.bE(prticore_b2920:6467)
tc-runner_1 | at se.pitch.prti1516e.lrc.MyFederate.e(prticore_b2920:6421)
tc-runner_1 | at se.pitch.prti1516e.lrc.MyFederate.aT(prticore_b2920:6342)
tc-runner_1 | at se.pitch.prti1516e.lrc.y.run(prticore_b2920:91)
tc-runner_1 | at java.lang.Thread.run(Thread.java:745)
tc-runner_1 | Caused by: java.lang.NullPointerException
tc-runner_1 | at de.fraunhofer.iosb.tc_lib_encodingrulestester.HlaDataFixedRecordType.testBuffer(HlaDataFixedRecordType.java:143)
tc-runner_1 | at de.fraunhofer.iosb.tc_lib_encodingrulestester.EncodingRulesTesterBaseModel.doReflectAttributeValues(EncodingRulesTesterBaseModel.java:986)
tc-runner_1 | at de.fraunhofer.iosb.tc_lib_encodingrulestester.EncodingRulesTesterBaseModel.reflectAttributeValues(EncodingRulesTesterBaseModel.java:1020)
tc-runner_1 | at de.fraunhofer.iosb.tc_lib.IVCT_LoggingFederateAmbassador.reflectAttributeValues(IVCT_LoggingFederateAmbassador.java:550)
tc-runner_1 | at se.pitch.prti1516e.lrc.t.reflectAttributeValues(prticore_b2920:1006)
tc-runner_1 | ... 8 more
Ps. in the log there is a message DISPLAY SOME HELPER VERSION NUMBER TO CONFIRM VERSION USED: 2018-12-12
. Maybe you could add the time to it, since there may be more than one build version per day.
This message is purely maintained by hand. Would need a script to change the message before check in. The important information is to know which version of the software is being used. GitHub does not offer much help in terms of embedding a version into the code.
Another option is to set the build-timestamp/version in the Dockerfile as an environment variable. I already do something similar for the LRC base image with the environment variable LRC_VERSION. This is set during the container image build.
I'll open a new issue for this, just to track it independently from here.
The null pointer exception came from the situation where a built-in simple datatype ("HLAASCIIchar") was not instantiated. Have added "HLAASCIIchar" as a datatype and can test the above buffer correctly. Still need to add the remaining simple datatypes from the IEEE 1516 OBJECT MODEL TEMPLATE (OMT) SPECIFICATION.
Actually, there is one already: #155
Added the remaining simple datatypes from the IEEE 1516 OBJECT MODEL TEMPLATE (OMT) SPECIFICATION. The java.lang.NullPointerException should be fixed now.
I have rerun the tests against VRF. Results seem generally ok, but I see here and there some encoding error.
Attached the TC Runner logfile.
The following is based on the assumption that the SOM file has the current and correct data types: if not then the SOM file has to be updated and the tests run again. Here is the analysis of a couple of errors: 1) Object class: HLAobjectRoot.EmitterBeam.RadarBeam Attribute: TrackObjectIdentifiers DataType: RTIobjectIdArray which is encoded as HLAvariableArray. The standard (IEEE1516.2-2010) says: The “HLAvariableArray” encoding is intended for arrays with variable (including dynamic) cardinality, and consists of the number of elements encoded as an HLAinteger32BE, followed by the encoding of each element in sequence. The expected coding is thus 00000002000100 which would mean two objects: a null object and an object with the value of 01 The buffer received is 000100 which is thus seems to be incorrect. The question here is: is it really incorrect? If so can we contact someone at shipsim about this? 2) Object class: HLAobjectRoot.EmbeddedSystem.EmitterSystem Attribute: EmitterType DataType: EmitterTypeEnum16 which is encoded as RPRunsignedInteger16BE. This is a non-standard basic type encoding name. The test tool cannot handle this properly. The test tool has to be enhanced to handle this type: not too difficult to do. This problem will always occur when extending the basic types. The test tool will be extended to handle the following: RPRunsignedInteger16BE, RPRunsignedInteger32BE, RPRunsignedInteger64BE and RPRunsignedInteger8BE. Once the changes are made, the tests can be re-run.
The following basic data types have been added: RPRunsignedInteger16BE, RPRunsignedInteger32BE, RPRunsignedInteger64BE and RPRunsignedInteger8BE plus some others which were missing.
in answer to: 1- this data is produced by VR Forces, a commercial CGF. I may be wrong, but I do not expect this data to be wrong. The CGF is around a long time and used in many simulations. If this issue needs follow-up, someone from the CGF provider has to be involved. 2- I will rerun the test and report back.
I reran the encoding test against both Shipsim and VR Forces. Shipsim creates a single entity, whereas VR Forces creates a larger scenario with several object instances and interactions.
I just ran the composition from Kubernetes, and whatever is latest got pulled from the Docker Hub. The IVCT is started before the test federate.
Attached the log files. Also in Shipsim there are ERROR reports, but I cannot make out the problem really.
Note that you can run the Shipsim test also locally from your lab.
I also ran the encoding tests with the MaK RTI using shipsim. Attached the docker-compose file and the resulting log.
docker-compose.txt vtmak-shipsim.txt pitch-shipsim.txt
The encoding tests with the MaK RTI result in TEST BUFFER INCORRECT errors for all attributes. The same test with the Pitch RTI runs fine, no errors.
I can only think of differences between the EncoderFactories used. Which one is correct?
I have looked at the logs posted on 5 Apr above and find it very strange that the identical buffer value in vtmak-shipsim.txt and pitch-shipsim.txt is considered incorrect in the first file and correct in the second. This value and other values which are not identical for the RTIs were checked and found to be correctly coded. There must be some problem when using the MaK RTI which causes all buffer values to be deemed incorrect: e.g. a test case / test system version problem or a FOM/SOM file version problem.
The only difference in this instance is the RTI and the encoder library used. The executable (shipsim) and the FOM are identical.
You can run the test yourself actually. The shipsim image (for Pitch and MaK) is available from the MSaaS Docker Registry. The Docker compose files are in GitHub.
Since the original reported issue may have been fixed in the meantime, I propose to close this issue an open new issues for the newly found issues. ok?
Have used a number of data buffer values from the log which were found incorrect and analyzed the program output which was often not useful. These messages have been improved to help explain the problem. The error handling was not always robust leading to null pointer problems and this has also been corrected.
When I run the encoding TS against VRF (using the Pitch RTI) I see several stacktraces in the log. I have attached a couple below.