7.8. Regressions in 6.0.0

The following regressions occur in Connext 6.0.0.

7.8.1. Core Libraries

Issues in the Core Libraries may affect components that use these libraries, including services and tools.

7.8.1.1. Fixed in 7.1.0 and 6.1.2

7.8.1.1.1. Creating DynamicDataTypePlugin with TypeCode from discovery and using content filtering causes segmentation fault

If the TypeCode that is received from endpoint discovery data (PublicationBuiltinTopicData.type_code or SubscriptionBuiltinTopicData.type_code) is used to create a DynamicDataTypeSupport in an application that is also using ContentFilteredTopics and setting ResourceLimitsQosPolicy.type_code_max_serialized_length to a non-zero value, the application issues a segmentation fault.

ResourceLimitsQosPolicy.type_code_max_serialized_length is 0 by default, so the underlying representation of PublicationBuiltinTopicData.type_code and SubscriptionBuiltinTopicData.type_code is stored in a deserialized format that is retrieved from the TypeObject and that will not cause a segmentation fault.

When ResourceLimitsQosPolicy.type_code_max_serialized_length is non-zero, the underlying representation of PublicationBuiltinTopicData.type_code and SubscriptionBuiltinTopicData.type_code is stored in a serialized format from the wire, which causes the segmentation fault in the ContentFilteredTopic implementation. This issue is fixed in releases 6.0.1.30, 6.1.2, and 7.1.0

[RTI Issue ID CORE-12992]

7.8.1.1.2. Crash with NULL listeners and non-none status masks in C applications that mix types with and without Zero Copy

In a C application, a crash occurs when the following is true:

  • Types with and without Zero Copy transfer over shared memory are mixed inside the same DomainParticipantFactory instance.

  • A DataReader or DataWriter of the non-Zero Copy types has a NULL listener and a DDS_StatusMask other than DDS_STATUS_MASK_NONE.

The crash occurs because Connext invokes a NULL listener callback for the statuses enabled in the endpoints’ DDS_StatusMask. This problem is fixed in releases 6.0.1.30, 6.1.2, and 7.1.0.

[RTI Issue ID CORE-13151]

7.8.1.1.3. Application using Monitoring Libraries produces segmentation fault during DataReader creation

In 6.0.x releases and above, an application using the Monitoring Library may have produced a segmentation fault during DataReader creation. The issue was very rare and only occurred if a DataReader received a sample immediately after being enabled. This issue is fixed in releases 7.1.0 and 6.1.2.

[RTI Issue ID MONITOR-429]

7.8.1.2. Fixed in 7.0.0 and 6.1.2

7.8.1.2.1. Continuous creation of TopicQueries may lead to unnecessary memory fragmentation in OS memory allocator

Starting in 6.0.0, the continuous creation of TopicQueries may lead to unnecessary memory fragmentation in the OS memory allocator of the applications that receive the TopicQuery requests and dispatch responses.

This issue may result in an unexpected increase of the resident set size (RSS) memory of the application receiving and dispatching the TopicQueries compared to previous Connext releases.

This problem has been fixed in releases 7.0.0 and 6.1.2.

[RTI Issue ID CORE-12352]

7.8.1.3. Fixed in 6.1.1

7.8.1.3.1. XSD issue: order enforced in <publisher> tag

In 6.0.0, the XSD definition file https://community.rti.com/schema/6.0.0/rti_dds_profiles.xsd, which is used by all Connext products, including Connext Micro, now shows an error when the <data_writer> or <data_reader> tag is placed after the <publisher_qos> or <subscriber_qos> tag:

"The element 'publisher' has invalid child element 'data_writer'.":

The following XML snippet was valid in 5.3.1, but now gives an error in 6.0.0:

<publisher name="MyPublisher">
    <publisher_qos/>
    <data_writer name="MyWriter" topic_ref="MyTopic">
        <datawriter_qos base_name="MyQos"/>
    </data_writer>
</publisher>

To avoid this error, change your XML as follows:

<publisher name="MyPublisher">
    <data_writer name="MyWriter" topic_ref="MyTopic">
        <datawriter_qos base_name="MyQos"/>
    </data_writer>
    <publisher_qos/>
</publisher>

This problem has been fixed in release 6.1.1.

[RTI Issue ID CORE-9374]

7.8.1.3.2. Invalid key deserialization for mutable derived types with key members

Starting in 6.0.0, the key deserialization for mutable derived types with key members when the base does not contain keys was invalid. For example:

@mutable
struct Base1 {
    long m1;
};

@mutable
struct Derived1 : Base1 {
    @key long m2;
};

This issue affected the following functionality:

  • Calling the APIs DataWriter::get_key_value and DataReader::get_key_value returned an invalid value.

  • When writer_qos.protocol.serialize_key_with_dispose was set to TRUE (not the default value) and writer_qos.protocol.disable_inline_keyhash was set to TRUE (not the default value), the keyhash calculated on the DataReader for a dispose sample sent by a DataWriter was invalid. This led to a situation in which a disposed instance was not reported as such on the DataReader side.

This issue affected all language bindings except Java and the legacy .NET API. It also affected DynamicData.

This problem has been resolved in release 6.1.1.

[RTI Issue ID CORE-11378]

7.8.1.3.3. Malformed samples with invalid strings not dropped by DataReader in C, traditional C++, and modern C++

In 6.0.0, a DataReader may have provided the application a malformed sample containing an invalid value (not null-terminated) for a string member. The string member may not have been null-terminated, resulting in undefined behavior if the application tried to access it.

This issue has been addressed in release 6.1.1. The DataReader will fail to deserialize the sample, and the sample will not be provided to the application.

[RTI Issue ID CORE-11203]

7.8.1.4. Fixed in 6.1.0

7.8.1.4.1. Unexpected log message when calling DataWriter::get_matched_subscription_data or DataReader::get_matched_publication_data on unmatched endpoints

The DataWriter::get_matched_subscription_data and DataReader::get_matched_publication_data APIs return RETCODE_PRECONDITION_NOT_MET when called using subscription or publication handles of endpoints that do not match with the calling endpoint. This is normal operation for the API and should not produce any logging messages at the exception log level; however, starting in release 6.0.0, an exception was printed in this case.

This issue has been fixed in release 6.1.0. In release 6.1.0, the log message is now printed at the warning log level, as was the case in releases previous to 6.0.0.

[RTI Issue ID CORE-10163]

7.8.1.5. Fixed in 6.0.1

7.8.1.5.1. XSD issues

7.8.1.5.1.1. Order enforced in <domain_participant> tag

In 6.0.0, the XSD definition file https://community.rti.com/schema/6.0.0/rti_dds_profiles.xsd, which is used by all Connext products, including Connext Micro, now enforces a specific ordering for tags within the <domain_participant> tag in the <domain_participant_library> tag.

The following XML example was valid in 5.3.1, but not in 6.0.0:

<?xml version="1.0" encoding="UTF-8"?>
<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="https://community.rti.com/schema/6.0.0/rti_dds_profiles.xsd">  <!-- QoS Profiles -->
    <qos_library name="QosLibrary">
        ...
    </qos_library>  <!-- Domains -->
    <domain_library name="DomainLibrary">
        <!-- Shape -->
        <domain name="Shape" domain_id="0">
            ...
    </domain>  <!-- Participants -->
    <domain_participant_library name="DomainParticipantLibrary">
        <!-- Shape -->
        <domain_participant name="ShapePublisher" domain_ref="DomainLibrary::Shape">
            <participant_qos base_name="QosLibrary::Base">
                ...
            </participant_qos>
            <publisher name="Publisher">
              ...
            </publisher>
        </domain_participant>
        <domain_participant name="ShapeSubscriber" domain_ref="DomainLibrary::Shape">
            <participant_qos base_name="QosLibrary::Base">
              ...
            </participant_qos>
            <subscriber name="Subscriber">
              ...
            </subscriber>
       </domain_participant>
   </domain_participant_library>
</dds>

The validation of this example using the XSD (https://community.rti.com/schema/6.0.0/rti_dds_profiles.xsd) will fail because the <publisher> tag should now appear before the <participant_qos> tag.

For example, using the above XML in Routing Service 6.0.0 will raise the following errors:

[/routing_services/default|CREATE] line XXX: Element 'publisher': This element is not expected.
[/routing_services/default|CREATE] line XXX: Element 'subscriber': This element is not expected.

This problem is fixed in release 6.0.1.

[RTI Issue ID CORE-9306]

7.8.1.5.1.2. XSD validation fails if topic_ref or register_type_ref uses some non-alphanumeric characters

In 6.0.0, XSD validation of an XML application creation file now fails if there are DataWriter topic_ref and register_type_ref attributes using non-alphanumeric characters such as ‘#’.

The only strings allowed are those matching this pattern:

((::)?[a-zA-Z0-9_.])+

If you want to use non-alphanumeric characters to specify the name of a Topic (although doing so is non-compliant with the OMG DDS standard), use the <registered_name> tag, which is available in both <register_type> and <topic> tags. For example:

...
<domain_participant name="participant">
    ...
    <topic name="MyTopic" register_type_ref="regType">
        <registered_name>com/rti/example/MyTopic</registered_name>
    </topic>
    ...
   <data_writer name="writer" topic_ref="MyTopic"/>
</participant>
...

This problem is fixed in release 6.0.1 to allow the non-alphanumeric characters.

[RTI Issue ID CORE-9484]

7.8.1.5.2. Dynamic Data issues

7.8.1.5.2.1. Segmentation fault when using unkeyed DynamicData DataReader with content filter and writer-side filtering

In 6.0.0, a DataReader may receive samples that do not match the content filter being used by the DataReader, even if the DataWriter is performing writer-side filtering. This could happen for two reasons:

  • The DataReader changes its filter after the DataWriter writes the sample, and the sample passes the DataReader’s previous filter.

  • There is another DataReader at the same locator that should receive the sample.

An unkeyed DynamicData DataReader that receives a sample due to the second reason above may segfault while attempting to return the sample resources after dropping the filtered sample.

This problem is fixed in release 6.0.1.

[RTI Issue ID CORE-9653]

7.8.1.5.2.2. Invalid serialization of samples with types containing primitive members that require padding

See more information in Section 7.8.3.2.1.

7.8.1.5.2.3. Possible data corruption or crash when using DynamicData and a type with inheritance

In 6.0.0, when using DynamicData and a type with inheritance, there is a possibility for data corruption or a crash when receiving the data. This error happens if the inherited base type contains one or more members of the following types:

  • A sequence of complex members (structs, sequences, unions, array)

  • An optional member of a complex type

The complex members mentioned above have to themselves contain at least one of:

  • a string

  • a sequence (of any kind)

  • an optional member

In addition, if the complex member is mutable, any member of the complex member that is not explicitly sent will not be initialized during deserialization to the correct default value if the default is something other than 0 (for example, through the use of the @default annotation or an enumeration with a non-zero default enumerator).

For example, the following type may exhibit this behavior because the BaseType contains a sequence of complex members that contain a string:

struct ComplexMember {
    string myString;
};

struct BaseType {
    sequence<ComplexMember> myComplexSequence;
};

struct DerivedType : BaseType {
    long myLong;
};

This problem is fixed in release 6.0.1.

[RTI Issue ID CORE-9821]

7.8.1.5.2.4. Missing parameter checking for several DynamicData APIs results in segmentation faults or incorrect return codes

In 6.0.0, calling the following functions results in a segmentation fault if the self parameter is NULL:

  • DynamicDataTypeSupport::unregister_type

  • DynamicDataTypeSupport::get_data_type

  • DynamicDataTypeSupport::get_type_name

DynamicDataTypeSupport::register_type incorrectly returned RETCODE_ERROR instead of RETCODE_BAD_PARAMETER when a NULL value was passed in for any of the parameters.

This problem is fixed in release 6.0.1.

[RTI Issue ID CORE-9832]

7.8.1.5.2.5. Binding to unset optional member causes some operations on parent DynamicData object to fail

In 6.0.0, binding to an unset optional member causes some operations to fail if the optional member is not unbound from before the operation is executed. The operations that fail are DynamicData::equals, DynamicData::print, and DynamicData::write. These operations behave as though the unset optional member is set. For example, the print operation prints the unset optional member, and the write operation sends it on the wire.

This behavior is most likely to be observed when using hierarchical naming because using hierarchical names causes members in the DynamicData object to be bound implicitly. These members are not unbound until a different member in the DynamicData object is accessed.

This problem is fixed in release 6.0.1.

[RTI Issue ID CORE-9685]

7.8.1.5.3. Discovery does not complete, and there is no error

In 5.3.1 and below, DomainParticipant announcement messages (DATA(P)) could be sent on the wire as long as the message size, including the RTPS overhead, was not greater than the minimum message_size_max across all installed transports. If the message size exceeded this limit, you would have seen the following error:

PRESPsWriter_writeInternal:!failed to write sample in Commend
DISCSimpleParticipantDiscoveryPluginPDFListener_onAfterLocalParticipantEnabled:!write
MIGGenerator_addData:serialize buffer too small
COMMENDAnonWriterService_onDomainBroadcastEvent:!add DATA to MIG

In 6.0.0, this behavior changed such that if the size of the DATA(P) messages without including the RTPS overhead, minus 512 bytes, is greater than the minimum message_size_max across all installed transports, the message is incorrectly fragmented by the builtin DataWriter. Additionally, since the builtin ParticipantBuiltinTopicData DataReader does not support fragmentation, it fails to reassemble the fragmented messages, and discovery does not complete. No error is printed, either.

Practically speaking, the maximum size of the DATA(P) messages that can be sent on the wire is reduced in 6.0.0. Messages that would have made it through in 5.3.1 do not in 6.0.0.

This problem is fixed in release 6.0.1.

Note

When DomainParticipant announcements need to be fragmented, discovery does not complete in any release. The solution in any release is to increase the transport message_size_max property or decrease the size of the DomainParticipant announcements.

[RTI Issue ID CORE-9872]

7.8.1.5.4. Crash when deserialized_type_object_dynamic_allocation_threshold set to 0

In 6.0.0, Connext applications that set deserialized_type_object_dynamic_allocation_threshold to zero (in the DomainParticipantQos’s ResourceLimits QosPolicy) may have crashed if endpoint_type_object_lb_serialization_threshold in the DomainParticipantQos’s DISCOVERY_CONFIG QosPolicy was set to a value other than -1.

This problem is fixed in release 6.0.1.

[RTI Issue ID CORE-9532]

7.8.1.5.5. Wrong return code for DDS::DataWriter::get_matched_subscription_data and DDS::DataReader::get_matched_publication_data

In 6.0.0, DDS::DataWriter::get_matched_subscription_data and DDS::DataReader::get_matched_publication_data incorrectly return DDS_RETCODE_ERROR instead of DDS_RETCODE_PRECONDITION_NOT_MET when the instance handle does not correspond to any matched endpoint. This problem may affect application logic that was expecting DDS_RETCODE_PRECONDITION_NOT_MET. This problem also affects APIs that use exceptions instead of return codes (modern C++, Java, and .NET).

This problem is fixed in release 6.0.1.

[RTI Issue ID CORE-9232]

7.8.1.5.6. DataReader reports incorrect sample lost and rejected when receiving coherent set

In 6.0.0, there is an issue that provokes DataReaders receiving a coherent set to incorrectly increment the sample lost and sample rejected count statistics, and to incorrectly call the onSampleLost() and onSampleRejected() callbacks. When this issue is triggered, the following warnings are logged:

PRESCstReaderCollator_addCollatorEntryToPolled:!assert instance
PRESCstReaderCollator_assertInstance:!keyhash not available, dropping the sample...

This problem is fixed in release 6.0.1.

[RTI Issue ID CORE-9576]

7.8.1.5.7. QoS policies not resolved to correct values

In 6.0.0, the implementation of Qos Profile composition (see “XML multiple inheritance” in What’s New in 6.0.0) introduced a regression. Consider this example:

<qos_profile name="Parent">
    <datawriter_qos name="DW_InParent" base_name="BuiltinQosLibExp::Generic.StrictReliable">
    <!-- Values specified by DW_InParent -->
    </datawriter_qos>
</qos_profile>

<qos_profile name="Child">
    <datawriter_qos name="DW_IncorrectValues" base_name="Parent" />
</qos_profile>

In this example, “DW_IncorrectValues” points to “Parent,” which is not a <datawriter_qos> but a <qos_profile>. Therefore, Connext should inherit values from the following elements, in order:

  1. BuiltinQosLibExp::Generic.StrictReliable (and its parents, and their parents if any)

  2. Values set in XML by “DW_InParent”

There is a problem, however, with the way Connext populates parents in this scenario. As a result, Connext only copies values set in XML by “DW_InParent,” ignoring the QoS parent value “BuiltinQosLibExp::Generic.StrictReliable” specified in the base_name attribute, giving incorrect results.

A workaround is to change your XML file so that <xxx_qos> points directly to another <xxx_qos> and not a <qos_profile>. In this example, you would make the following correction:

<qos_profile name="Child">
    <datawriter_qos name="DW_IncorrectValues" base_name="DW_InParent" />
</qos_profile>

This problem is resolved in 6.0.1 by fixing the internal logic to populate parent values correctly. In 6.0.1, when the inherited <qos_profile> contains an <xxx_qos> having its own base_name attribute value, Connext will find and return the correct QoS values.

For more information on QoS Profile Inheritance, see the “QoS Profile Inheritance” section in the RTI Connext DDS Core Libraries User’s Manual.

[RTI Issue ID CORE-9376]

7.8.2. Security Plugins

7.8.2.1. Fixed in 7.2.0

7.8.2.1.1. Discovery time scaled poorly

In 6.0.0, endpoint discovery time scaled poorly as the number of endpoints increased. Moreover, when using the Lightweight Builtin Security Plugins or the Builtin Security Plugins running under HMAC-Only mode, participant discovery time incorrectly did not scale as the number of participants increased.

This problem is fixed in release 7.2.0.

[RTI Issue ID SEC-2170]

7.8.2.2. Fixed in 6.0.1

7.8.2.2.1. Possible lack of SUBSCRIPTION_MATCHED_STATUS if a DataWriter loses liveliness with the DataReader

In 6.0.0, there is a race condition in which a DataReader may never report a SUBSCRIPTION_MATCHED_STATUS change despite successfully matching and receiving data from a DataWriter. This race condition occurs if all of the following conditions are true:

  • The DataReader sets its liveliness lease_duration to a very small duration (on the order of milliseconds).

  • The DataReader is communicating with a DataWriter with metadata_protection_kind or data_protection_kind set to a value other than NONE.

  • The DataWriter loses liveliness with the DataReader between the time the DataReader discovers the DataWriter and the time the DataReader receives key material from the DataWriter.

  • The DataWriter regains liveliness with the DataReader before the DataReader receives key material from the DataWriter.

    Note

    This condition is the opposite of the fourth condition in RTI Issue ID SEC-895, which is fixed in 6.0.0. (See What’s Fixed in 6.0.0 in the RTI Security Plugins Release Notes.)

This problem is fixed in release 6.0.1.

[RTI Issue ID SEC-911]

7.8.2.2.2. Applications directly calling OpenSSL APIs after DomainParticipant deletion may crash

In 6.0.0, the destruction of all the DomainParticipants loading Security Plugins results in the plugins calling OpenSSL’s EVP_cleanup and ERR_free_strings APIs to clean up OpenSSL state. As a result, if an application running Connext invokes OpenSSL APIs after this cleanup takes place without reinitializing OpenSSL, the application may run into unexpected OpenSSL behavior or even a crash.

OpenSSL 1.1.0 deprecated both EVP_cleanup and ERR_free_strings, and they have no effect anymore. Since release 6.0.1 is using OpenSSL 1.1.1d, the previously described problem is fixed in release 6.0.1.

This problem is fixed in release 6.0.1.

[RTI Issue ID SEC-1031]

7.8.2.2.3. DataWriter does not report PUBLICATION_MATCHED_STATUS for DataReaders that are inactive when it receives their key material

In 6.0.0, under the following sequence of events, a DataWriter setting <metadata_protection_kind> or <data_protection_kind> to a value other than NONE never reports PUBLICATION_MATCHED_STATUS for a DataReader:

  1. The DataWriter discovers the DataReader.

  2. The DataReader becomes inactive after writer_qos.protocol.rtps_reliable_writer.max_heartbeat_retries Heartbeats (HBs) due to the lack of response to HBs (default behavior) or to not making progress on the NACK messages (non default - requires setting writer_qos.protocol.rtps_reliable_writer.inactivate_nonprogressing_readers to TRUE).

  3. The DataWriter receives key material from the DataReader.

  4. The DataReader becomes active after starting to respond to HBs and/or making progress on the NACK messages.

  5. The DataWriter incorrectly does not report PUBLICATION_MATCHED_STATUS for a DataReader.

This problem is fixed in release 6.0.1.

[RTI Issue ID SEC-1013]

7.8.3. Code Generator

7.8.3.1. Fixed in 6.1.1

7.8.3.1.1. 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

This regression was introduced in 5.3.0; however, with the default optimization level change to 2 in 6.0.0 (see Section 6.2.6.9), the behavior described here is the default behavior in releases 6.0.0, 6.0.1, and 6.1.0. This problem has been fixed in release 6.1.1.

Currently, using the -optimization command-line option with value 1 or 2 (default is 2) replaces the use of superfluous alias types with the equivalent primitive, enum, or aggregated types.

For example, consider the following IDL:

typedef long MyLong;

struct MyStruct {
    MyLong m1;
}

The C output with -optimization 1 or 2 would be as follows:

struct MyStruct {
    int m1;
}

The C output with -optimization 0 would be as follows:

struct MyStruct {
    MyLong m1;
}

The problem with this behavior is that sequences with typedef elements that are bounded strings are resolved to DDS_StringSeq, which represents a sequence of unbounded strings.

For example, consider the following IDL:

typedef string<128> MyBoundedString;

struct MyStruct {
    sequence<MyBoundedString> m1;
}

The C output with -optimization 0 would be as follows:

struct MyStruct {
    MyBoundedStringSeq m1;
}

The C output with -optimization 1 or 2 would be as follows:

struct MyStruct {
    DDS_StringSeq m1;
}

Unfortunately, the semantic of unbounded string sequences is different from the semantic of bounded string sequences. Specifically, calling maximum in an unbounded string sequence allocates a buffer with NULL strings, whereas calling maximum in a bounded string sequence allocates the string elements to their maximum size.

This regression only affects C and traditional C++. It is not a problem in modern C++ because sequences of bounded and unbounded strings are treated as unbounded sequences. The problem is fixed in release 6.1.1.

[RTI Issue ID CODEGENII-1489]

7.8.3.1.2. Invalid key deserialization for mutable derived types with key members

See Invalid key deserialization for mutable derived types with key members above.

7.8.3.1.3. Malformed samples with invalid strings not dropped by DataReader in C, traditional C++, and modern C++

See Malformed samples with invalid strings not dropped by DataReader in C, traditional C++, and modern C++ above.

7.8.3.2. Fixed in 6.0.1

7.8.3.2.1. Invalid serialization of samples with types containing primitive members that require padding

In 6.0.0, serialization of samples with a type containing a nested complex type with primitive members that require padding may fail. This means that a DataReader may receive an invalid value for a sample.

Example:

@nested struct Struct_3 {
    float m1;
    long long m2;
    short m3;
};

@nested struct Struct_2 {
    Struct_3 m1;
};

struct Struct_1 {
    Struct_2 m1;
};

In this example, Struct_3 is nested and there is padding between m1 (4-byte aligned) and m2 (8-byte aligned) of 4 bytes.

This problem affects the generated code for the following languages: C, C++, C++03, and C++11. It also affects DynamicData in all languages.

For generated code, a potential workaround for this problem is to generate code with a value of 1 for the -optimization, but this may have performance implications.

This problem is fixed in release 6.0.1.

[RTI Issue IDs CODEGENII-1196 and CORE-9777]

7.8.3.2.2. Java exception during serialization/deserialization of keyed types whose key is an unkeyed nested type with unbounded members

In 6.0.0, the keyhash max size calculation is wrong in Java when generating certain types using the rtiddsgen -unboundedSupport option. Specifically, this issue affects keyed types whose key is an unkeyed nested type with unbounded members. An example of that type is the following:

@nested
struct MyNestedStruct {
    long myLong;
    string myString2;
};

struct MyStruct {
    MyNestedStruct myType; //@Key
};

As a result of this problem, an application in Java using these kinds of types might throw an exception or produce a hang.

This problem is fixed in release 6.0.1.

[RTI Issue ID CODEGENII-1194]

7.8.3.2.3. Incorrect deserialization in .Net of samples from certain types when published from a writer with disable_inline_keyhash set to true

In 6.0.0, the deserialization in .Net of a sample of a type that has inheritance, where the basetype has both keys and optional members, is incorrect if the sample is published by a DataWriter, of any language, that has set the writer_qos.protocol.disable_inline_keyhash QoS to true.

An example of this type would be the following.

struct Shape1Final {
  @key
  string<128> color;
  @optional
  string<128> description;
  long shapesize;
};

struct Shape5Final : Shape1Final {
    double angle;
};

As a result of this problem, the .Net subscriber might report an error like the following and not be able to deserialize the received sample:

PRESCstReaderCollator_serializedKeyOrSampleToKeyHash:!serialized sample to keyhash
PRESCstReaderCollator_getSampleKeyHashes:!serialized key/sample to keyhash
PRESCstReaderCollator_storeInlineQos:!get sample keyHashes
PRESCstReaderCollator_storeSampleToEntry:!store inline qos in entry
PRESCstReaderCollator_newData:!get entries

This problem is fixed in release 6.0.1.

[RTI Issue ID CODEGENII-1208]

7.8.3.2.4. Generated code in traditional C++ with namespaces for an IDL containing a nested module called “rti” will not compile

In 6.0.0, the generated code for traditional C++ does not compile if a module is called “rti” and the code is generated with -namespace. For example:

module com {
    module rti {
        struct Foo {
            long m1;
        };
    };
};

You will see errors like the following one:

FooDataPlugin.cxx: In function ‘RTIXCdrInterpreterPrograms*
com::rti::media::generated::FooPlugin_get_programs()’:
FooDataPlugin.cxx:882:33: error: ‘com::rti::xcdr’ has not been
declared
                    return rti::xcdr::get_cdr_serialization_programs<

This problem is fixed in release 6.0.1.

[RTI Issue ID CODEGENII-1099]

7.8.4. Routing Service

7.8.4.1. Fixed in 6.1.1

7.8.4.1.1. Unbounded memory growth when restarting Service or creating/deleting DomainRoutes

When using Routing Service as a library, starting and stopping Routing Service instances within the same process may lead to an unbounded memory growth with a small memory increment every time an instance is stopped.

Creating and deleting DomainRoutes within a Routing Service instance may also lead to an unbounded memory growth with a small memory increment every time a DomainRoute is deleted.

This problem is fixed in release 6.1.1.

[RTI Issue ID ROUTING-833]

7.8.4.2. Fixed in 6.1.0

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

In 6.0.0, RTI::RoutingService::create_entity incorrectly fails if the XML snippet string provided as an argument starts with the string URI str://. Previously, str:// was expected/required for string URIs; now RTI::RoutingService::create_entity fails when str:// is provided.

This problem is fixed in release 6.1.0.

[RTI Issue ID ROUTING-606]

7.8.4.3. Fixed in 6.0.1

7.8.4.3.1. Executable ignores logging QoS

In 6.0.0, logging settings specified in the DomainParticipantFactory QoS are ignored when running the shipped Routing Service application. (This problem does not occur when you deploy Routing Service as a library linked into your application.) To work around this problem, set the logging format through the command line (using the -logFormat option) when using the shipped Routing Service application.

This problem is fixed in release 6.0.1.

[RTI Issue ID ROUTING-641]

7.8.5. Recording Service

7.8.5.1. Fixed in 6.0.1

7.8.5.1.1. Legacy deserialized database table cannot be replayed or converted if it contains compact byte sequences or arrays

In 6.0.0, replaying or converting a legacy (version 5.3.1 or older) database stored in deserialized format fails if the database is recorded with octet/char sequences/arrays stored as blobs (that is, in compact mode). For example:

struct LargeByteSeqType {
  sequence<octet, 65530> large_byte_seq;
  ...;
};

If the database stores large_byte_seq as a BLOB column, then Replay or Converter fails and complains with the following message:

exception:[DRT_DynamicType_expand_sequence_v3@3379]:Sequence length greater than built-in max

If you convert the legacy database so that it uses non-compact octet/char sequences/arrays, you may be able to work around this problem; however, non-compact octet/char sequences/arrays can also easily hit the column limit.

This issue is fixed in release 6.0.1.

[RTI Issue ID RECORD-957]

7.8.5.1.2. Segmentation fault in Replay Service or Converter if recorded topics have “::” in their names

In 6.0.0, this issue occurs when a DDS topic contains “::” as part of its name. Replay or Converter will hit a segmentation fault when trying to process that topic’s table.

This issue is fixed in release 6.0.1.

[RTI Issue ID RECORD-959]

7.8.6. Cloud Discovery Service

7.8.6.1. Fixed in 6.0.1

7.8.6.1.1. Cloud Discovery Service executable did not log build ID for DDS libraries

In 6.0.0, the DomainParticipantFactory initialization didn’t appear anywhere in the logging generated by Cloud Discovery Service for any verbosity level. Cloud Discovery Service printed the ROUTER build ID, but the “Welcome to NDDS” message, NDDS C, and NDDS Core Library build IDs weren’t printed.

This issue is fixed in release 6.0.1.

[RTI Issue ID CDS-51]