15.4. What’s Fixed in 7.6.0

This section describes bugs fixed in Routing Service 7.6.0. These are fixes since 7.5.0.

RTI® Connext® 7.6.0 is an early access releases. See the Connext Versions and Lifecycle page for more information on RTI’s software release model.

For what’s fixed in other products in the Connext suite, see those products’ release notes on the RTI Community Portal or in your installation.

[Critical]: System-stopping issue, such as a crash or data loss.
[Major]: Significant issue with no easy workaround.
[Minor]: Issue that usually has a workaround.
[Trivial]: Small issue, such as a typo in a log.

15.4.1. Serialization and Deserialization

15.4.1.1. [Critical] Unexpected error messages when Routing Service disposed of an instance while using batching and setting serialize_key_with_dispose to TRUE

Consider the following Routing Service writer QoS:

<datawriter_qos>
                <batch>
                    <enable>true</enable>
                </batch>
                <protocol>
                    <serialize_key_with_dispose>true</serialize_key_with_dispose>
                </protocol>
            </datawriter_qos>

The data type is keyed, and the serialized key is not aligned to a 4-byte boundary.

Imagine that Routing Service successfully sends one batch with a data sample of a given instance and then attempts to send another batch whose first sample is a dispose message for that same instance.

When using release libraries, Routing Service would have successfully sent the second batch, but the DataReader that was reading the batch from Routing Service would have experienced this error:

ERROR MIGInterpreter_parse:submessage not aligned to 4

When using debug libraries, Routing Service would have failed to send the batch and generated this error:

mig.2.0/srcC/generator/Generator.c:1216:RTI0x200003a:!precondition: "!(sample != ((void *)0) && (((sample)->serializedData[encapsulationIndex].serializedData.pointer == ((void *)0) || ((sample)->serializedData[encapsulationIndex].serializedData.length & 0x3) == 0)) && (((sample)->protocolParameters.pointer == ((void *)0) || ((sample)->protocolParameters.length & 0x3) == 0)))

This problem only affected 7.3.0 and above. Routing Service now successfully sends the batch, and the DataReader successfully receives the batch when using either release or debug libraries.

[RTI Issue ID ROUTING-1288]

15.4.2. Memory Leaks/Growth

15.4.2.1. [Minor] Memory leak if malformed configuration file prevents Routing Service creation

Suppose Routing Service attempts to use an XML configuration file that is malformed because of a missing closing quote in the xmlns attribute. For example:

xmlns=<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance>

Routing Service creation correctly fails with an error message containing RTIXMLUTILSParser_parseFile. However, in releases 6.0.0 and above, Routing Service also incorrectly leaked memory in the same function, RTIXMLUTILSParser_parseFile.

[RTI Issue ID ROUTING-1324]

15.4.3. Crashes

15.4.3.1. [Critical] Possible crash if custom transformation on input returned the provided input samples or sample infos as output

Note

In the 7.5.0. release, the release note “Possible crash if custom transformation returned the provided input samples or sample infos as output” (ROUTING-1236) was incomplete. The following release note adds additional context.

Routing Service could have crashed or had a memory corruption when using a custom Transformation on an input that returned the same array of samples or sample infos provided to it as outputs within its transform() method.

For example, the following code returned the collection of info objects, inInfoList, as the output list, outInfoLst.

void MyCustomTransformation_transform(
      RTI_RoutingServiceTransformation transformation,
      RTI_RoutingServiceSample **outSampleList,
      RTI_RoutingServiceSampleInfo **outInfoList,
      int *outCount,
      RTI_RoutingServiceSample *inSampleList,
      RTI_RoutingServiceSampleInfo *inInfoList,
      int inCount,
      RTI_RoutingServiceEnvironment * env)
{
   // ...

   *outCount = inCount;
   *outInfoList = inInfoList;

   // ...
}

This could have resulted in a memory corruption, crash, or just failure to route the samples. Routing Service now prints the following error messages when this condition is detected:

[/routing_services/RsTransformation/domain_routes/DomainRoute1/sessions/Session/routes/MyData/inputs/Input1] ROUTERStreamReader_readOrTakeI:!sample info list: transformation cannot return input sample info list as output; stream name=Example MyData
(...)

Implementers of the Transformation API should manage their own memory in their code, including the allocation and freeing of returned output arrays. The return_loan() function will be called to signal that any allocated memory provided as outputs can be freed.

[RTI Issue ID ROUTING-1236]

15.4.4. Other

15.4.4.1. [Critical] Routing Service didn’t allow configuration of its internal clock

Routing Service lacked the ability to configure its internal clock, causing it to malfunction in jump-time scenarios. To address this, a new XML tag, <internal_clock>, has been introduced, allowing you to specify a comma-delimited list of preferred clock sources: “realtime,” “system,” or “monotonic.” Clock configuration is also available via the command-line option -internalClock and within Service Properties, with these methods taking precedence over the XML tag.

[RTI Issue ID ROUTING-1299]

15.4.4.2. [Minor] Routing Service user library required inclusion in correct environment variable to be loaded

Previously, it was necessary for the Routing Service user library to be added to the LD_LIBRARY_PATH on Linux systems, DYLD_LIBRARY_PATH on macOS systems, or PATH on Windows systems. Additionally, it was necessary to ensure that the XML configuration specified only the library’s name, not its full DLL path. This issue has been addressed, and the user library no longer requires an environment variable to load correctly.

[RTI Issue ID ROUTING-1314]