#65 Unusual System Behavior with Variable Datum sizes greater than 64 bits

[Anonymous]

I have a Test Harness that publishes PDUs. Within my test harness I create a Data PDU with 3 variable datums (code snippet below). I wanted to test variable datum sizes greater than 64 bits so I modified the last variable datum to be 128 bits which is an acceptable number according the the IEEE DIS spec. Note 'SECONDS' is a 64 bit data type. I know that 'temp' is a 4 byte type but, there are no basic data types that are 16 bytes (128 bits).

std::vector<kdis::data_type::vardtmptr> variableDatum;
int temp = 0;
variableDatum.push_back(new KDIS::DATA_TYPE::VariableDatum((KDIS::DATA_TYPE::ENUMS::DatumID)_nDatum, (KDIS::KOCTET)&_gpsTime, sizeof(SECONDS) * 8));
variableDatum.push_back(new KDIS::DATA_TYPE::VariableDatum((KDIS::DATA_TYPE::ENUMS::DatumID)52340, (KDIS::KOCTET)&_gpsTime, sizeof(double) * 8));
variableDatum.push_back(new KDIS::DATA_TYPE::VariableDatum((KDIS::DATA_TYPE::ENUMS::DatumID)52340, (KDIS::KOCTET*)&temp, 16 * 8));
pDataPDU->SetVariableDatum(variableDatum);</kdis::data_type::vardtmptr>

My receieving program is able to decode the Data PDU but, it fails with a read access violation soon there after.

I set the bit size down to 64 and everything runs without a hitch.

Below is a snippet from a Wireshark capture showing the 128 bit representation of the last variable datum

Distributed Interactive Simulation
Header
Proto version: IEEE 1278.1A-1998 (6)
Exercise ID: 1
PDU type: Data (20)
Proto Family: Simulation management (5)
Timestamp: 0.001000000 seconds (relative)
PDU Length: 96
Padding: 0000
Data PDU
Originating Entity ID
Receiving Entity ID
Request ID: 204
Padding: 00000000
Number of Fixed Data Fields: 0
Number of Variable Data Fields: 3
Variable data
Datum ID: 52010
Datum length: 64
Datum value: 000000823ddfce41
Variable data
Datum ID: 52340
Datum length: 64
Datum value: 000000823ddfce41
Variable data
Datum ID: 52340
Datum length: 128
Datum value: 00000000ff00000000f83e0000000000

[Karl Jones]

Hmm interesting. Ill take a look.

[J V]

Are you sure it is your "receiving" program that incurs a Read Access Violation? You have a clear read access violation in your "transmitting" program. You are passing an address of an integer but specifying a bit size greater than an integer (32 vs 128). The VariableDatum constructor is going to perform an illegal memory access when it attempts to read beyond the first four bytes.
You simply need to declare a static buffer to pass to the VariableDatum constructor, instead of an integer...

char temp[16];
...
variableDatum.push_back(new KDIS::DATA_TYPE::VariableDatum((KDIS::DATA_TYPE::ENUMS::DatumID)52340, (KDIS::KOCTET*)temp, 16*8));

[Karl Jones]

Nice catch!

[Anonymous]

Thanks for the response!

I debugged the VariableDatum constructor code just to be sure. The transmitting program does not incur a Read Access Violation. The SetDatumValue code successfully places the pointer KOCTECT data into two DatumEntry objects that are then placed in the m_v8DatumValue vector (m_v8DatumValue holds a max of 64-bits so 2 entries in this vector makes sense). The datum value is successfully encoded and sent out over the wire as my wireshark capture above illustrates. NOTE: the data parameter is represented as a 64-bit memory address due to my systems archetecture.

I am wondering if there is an issue with the decoding of the variable datum.

[Anonymous]

Sorry I meant to say 'The transmitting program does not incur a Read Access violation'

[Karl Jones]

Its certainly possible. Does this issue happen with all PDU that support the datum type? Perhaps its a bug in the general PDU decoding?

[Anonymous]

I'll test with other PDUs that suport the variable datum type and see what happens.