5.2. Regressions in 6.0.1

The following regressions were introduced in 6.0.0 or 6.0.1.

5.2.1. Core Libraries

5.2.1.1. XSD Issue: order enforced in <publisher> tag

This regression was introduced in 6.0.0 and has not been fixed. See XSD issue: order enforced in <publisher> tag in the 6.0.0 Regressions section.

5.2.1.2. Memory leak modifying flow_controller_name or filter_name QoS programmatically with DDS_String_dup

This regression was introduced in 6.0.0 and has not been fixed. See Memory leak modifying flow_controller_name or filter_name QoS programmatically with DDS_String_dup in the 6.0.0 Regressions section.

5.2.1.3. Possible data corruption in multi-threaded serialization of strings on some platforms (Modern C++ API)

This regression was introduced in 6.0.0 and has not been fixed. See Possible data corruption in multi-threaded serialization of strings on some platforms (Modern C++ API) in the 6.0.0 Regressions section.

5.2.1.4. Samples lost if multiple readers were created in same locator and push_on_write was set to false

This regression was introduced in 6.0.1 and has not been fixed.

If push_on_write was set to false in a DataWriter’s DATA_WRITER_PROTOCOL QoS Policy, and multiple DataReaders were created in the same locator (same participant, same port), samples may have been lost.

This potential loss may have occurred when the second or subsequent DataReader was created. When the DataWriter detected the new DataReader, it sent an RTPS gap message, which may have gapped unsent samples. This was only an issue if push_on_write was set to false.

This problem will be fixed in an upcoming patch or release.

[RTI Issue ID CORE-11515]

5.2.1.5. XML parser crashed from infinite recursion when XML QoS configuration contained inheritance loop

This regression was introduced in 6.0.1 and has not been fixed.

An inheritance loop was formed when a <qos_profile> inherited from itself or when any <xxx_qos> inherited from itself or its encapsulating <qos_profile>. Inheritance can be performed by using the base_name attribute or <base_name> tag. In previous releases, Connext DDS ignored this inheritance loop, but in 6.0.1 it crashed.

The following XML, which was fine in previous releases, caused a crash in 6.0.1:

<qos_profile name="SetIdentityRequest" base_name="SkyKeeperProfile">
    <topic_qos name="SetIdentityRequest">
        <durability>
            <kind>VOLATILE_DURABILITY_QOS</kind>
        </durability>
    </topic_qos>

    <datawriter_qos base_name="SetIdentityRequest"> <!-- Infinite recursion -->
        <batch>
            <enable>true</enable>
            <max_flush_delay>
                <sec>0</sec>
                <nanosec>250000000</nanosec>
            </max_flush_delay>
        </batch>
    </datawriter_qos>

    <datareader_qos name="SetIdentityRequestReader">
        <base_name>
            <element>SetIdentityRequestReader</element>  <!-- Infinite recursion -->
            <element>ControlTowerProfile</element>
        </base_name>
</datareader_qos>
    </datareader_qos>
</qos_profile>

This problem will be fixed in an upcoming patch or release by producing an error, instead of a crash, if the parser detects the inheritance loop.

To work around this problem, remove the inheritance loop in your XML file. For example, revise the above XML file as follows:

<qos_profile name="SetIdentityRequest" base_name="SkyKeeperProfile">
    <topic_qos name="SetIdentityRequest">
        <durability>
            <kind>VOLATILE_DURABILITY_QOS</kind>
        </durability>
    </topic_qos>

    <datawriter_qos> <!-- Remove base_name attribute -->
        <batch>
            <enable>true</enable>
            <max_flush_delay>
                <sec>0</sec>
                <nanosec>250000000</nanosec>
            </max_flush_delay>
        </batch>
    </datawriter_qos>

    <datareader_qos> <!-- Remove the base_name tag element -->
        <base_name>
            <element>ControlTowerProfile</element>
        </base_name>
    </datareader_qos>
</qos_profile>

[RTI Issue ID CORE-11731]

5.2.1.6. Fixed in 6.1.0

5.2.1.6.1. Possible issues with communication and enabling DomainParticipant on Windows systems if network interface had multiple IP addresses

On Windows platforms, when a network interface has assigned more than one IP address, Connext DDS only detected the one with the lowest IP address. DomainParticipants running on a Windows host with this network configuration could not be discovered through the other IP addresses, causing communication issues.

Besides the communication issues, the DomainParticipant could not be enabled if the allow/deny_interfaces_list properties of the transport restricted the available IP addresses to the ones not reported and there was no other transport enabled on that DomainParticipant.

This regression was introduced in 6.0.1 and has been fixed in 6.1.0 and 6.0.1.20. Now, all the IP addresses of a network interface are detected and will work as expected.

[RTI Issue ID CORE-11232]

5.2.1.6.2. Failure to allocate memory larger than 2 GB

Connext DDS failed to allocate heap memory larger than 2 GB. For example, if the DataWriterQos’s resource_limits.initial_samples was large enough to cause a preallocation of more than 2 GB but less than the available heap memory, then DataWriter creation incorrectly failed.

This problem only affected releases 5.3.1.22 and 6.0.1, and has been fixed in release 6.1.0.

[RTI Issue ID CORE-10057]

5.2.2. RTI Code Generator

5.2.2.1. Change in behavior in C and traditional C++ for bounded sequences under certain conditions

This regression was introduced in 6.0.0 and has not been fixed. See Change in behavior in C and traditional C++ for sequences of bounded strings under certain conditions when code is generated with optimization level 1 or 2 in the 6.0.0 Regressions section.

5.2.3. RTI Routing Service

5.2.3.1. Fixed in 6.1.0

5.2.3.1.1. Create method in Service API fails to parse XML snippets that start with ‘str://’

See Create method in Service API fails to parse XML snippets that start with ‘str://’ in the 6.0.0 Regressions section.

5.2.4. RTI Recording Service

5.2.4.1. Fixed in 6.1.0

5.2.4.1.1. Crash if monitoring enabled and TopicGroup matched with Topic name containing ‘/’ character

Recording Service crashed if monitoring was enabled and a TopicGroup matched with a Topic name that contained one or more forward slash (‘/’) characters. This problem has been fixed in 6.1.0 and 6.0.1.7.

[RTI Issue ID RECORD-1153]

5.2.4.1.2. Segmentation fault after discovering application that used UserData QoS Policy

If Recording Service discovered an application that had at least one entity (DomainParticipant, DataReader, or DataWriter) that used the UserData QoS Policy, the behavior was undefined and would likely have resulted in a segmentation fault. This issue has been fixed in 6.1.0 and 6.0.1.3.

[RTI Issue ID RECORD-1125]

5.2.5. RTI Prototyper

5.2.5.1. Fixed in 6.1.0

5.2.5.1.1. Prototyper broken in 6.0.1

Changes to internal components in RTI Connector, which are shared with Prototyper, render Prototyper unusable in 6.0.1.

This problem is fixed in release 6.1.0; however, 6.1.0 is the last release in which Prototyper is supported. After 6.1.0, Prototyper will not be supported. RTI Connector replaces it and supports more scripting languages.

[RTI Issue ID PROT-89]