.. include:: /../getting_started/vars.rst .. _section-Regressions: Regressions in 6.0.0 ******************** The following regressions were introduced in *Connext* 6.0.0. Core Libraries ============== Issues in the Core Libraries may affect components that use these libraries, including services and tools. .. _CORE-14997: XCDR serialization of a mutable union with an unknown discriminator value is not compliant with OMG specification ----------------------------------------------------------------------------------------------------------------- A union's discriminator value may not select any member in the union. When this is the case, and when the union is mutable, the XCDR serialization of the union is not compliant with the `OMG 'Extensible and Dynamic Topic Types for DDS' specification, version 1.3 `__, because it is missing the 4-byte sentinel value ``02 7f 00 00`` at the end. This problem affects Dynamic Data in all language APIs and generated code in all language APIs except for Java. Due to this issue, |DRs| from releases before 6.0.0 may encounter deserialization failures when receiving samples from a |DW| in release 6.0.0 or later if mutable unions are used in the Topic type. **Fixed in:** 7.5.0 [RTI Issue ID CORE-14997] Participant may receive RTPS traffic over SHMEM transport not intended for participant -------------------------------------------------------------------------------------- A *DomainParticipant* using the shared memory (SHMEM) transport may receive RTPS traffic over SHMEM intended for a remote *DomainParticipant* running in a different host. This may lead to performance issues in large systems. The affected traffic includes *DomainParticipant* announcement traffic and NACK traffic sent from reliable *DataReaders* to reliable *DataWriters*. In addition, if you disable or limit the sending of transport information with the participant announcements (for example, you set ``participant_qos.resource_limits.transport_info_list_max_length`` to 0), the affected traffic is all traffic. **Fixed in:** 7.3.0 [RTI Issue ID CORE-13828] Instance handling on a DataReader and filtering operations in ContentFilteredTopics, QueryConditions, TopicQueries, and Multi-Channel DataWriters may fail ---------------------------------------------------------------------------------------------------------------------------------------------------------- You may experience invalid results in filtering operations when using ContentFilteredTopics, QueryConditions, TopicQueries, or Multi-Channel *DataWriters*. This issue may result in *DataReaders* not receiving samples they should. The following error message occurs: ``DDS_SqlFilter_evaluateOnSerialized:deserialization error: sample``. This issue may also cause failures on a *DataReader* when setting ``writer_qos.protocol.disable_inline_keyhash`` to TRUE on a matching *DataWriter*. This could lead to incorrect instance handling, where two different instances are considered the same. This problem is specific to *Topic* types containing optional members, and occurs when the *DataReaders* and *DataWriters* on the *Topic* use XCDR encapsulation. This problem affects all languages. It has been resolved in all languages but Java in release 7.2.0. **Fixed in:** 7.2.0 [RTI Issue ID CORE-13829] .. _CORE-12992: 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. **Fixed in:** 7.1.0 [RTI Issue ID CORE-12992] .. _CORE-13151: 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 |DR| or |DW| 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``. **Fixed in:** 6.1.2, 7.1.0 [RTI Issue ID CORE-13151] .. _MONITOR-429: Application using Monitoring Libraries produces segmentation fault during DataReader creation --------------------------------------------------------------------------------------------- An application using the Monitoring Library may have produced a segmentation fault during |DR| creation. The issue was very rare and only occurred if a |DR| received a sample immediately after being enabled. **Fixed in:** 6.1.2, 7.1.0 [RTI Issue ID MONITOR-429] .. _CORE-12352: Continuous creation of TopicQueries may lead to unnecessary memory fragmentation in OS memory allocator ------------------------------------------------------------------------------------------------------- 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. **Fixed in:** 6.1.2, 7.0.0 [RTI Issue ID CORE-12352] .. _section-xml-compatibility-publisher: XSD issue: order enforced in tag -------------------------------------------- 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 ```` or ```` tag is placed after the ```` or ```` tag: .. code-block:: bash "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: .. code-block:: xml To avoid this error, change your XML as follows: .. code-block:: xml **Fixed in:** 6.1.1 [RTI Issue ID CORE-9374] .. _section-CORE-11378: Invalid key deserialization for mutable derived types with key members ---------------------------------------------------------------------- The key deserialization for mutable derived types with key members when the base does not contain keys was invalid. For example: .. code-block:: text @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. **Fixed in:** 6.1.1 [RTI Issue ID CORE-11378] .. _section-CORE-11203: Malformed samples with invalid strings not dropped by DataReader in C, traditional C++, and modern C++ ------------------------------------------------------------------------------------------------------ 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. The *DataReader* will fail to deserialize the sample, and the sample will not be provided to the application. **Fixed in:** 6.1.1 [RTI Issue ID CORE-11203] 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. 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. **Fixed in:** 6.1.0 [RTI Issue ID CORE-10163] .. _section-xml-compatibility: XSD issues ---------- .. _section-9306: Order enforced in tag ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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 ```` tag in the ```` tag. The following XML example was valid in 5.3.1, but not in 6.0.0: .. code-block:: xml ... ... ... ... ... ... The validation of this example using the XSD (https://community.rti.com/schema/6.0.0/rti_dds_profiles.xsd) will fail because the ```` tag should now appear before the ```` tag. For example, using the above XML in |RS| 6.0.0 will raise the following errors: .. code-block:: bash [/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. **Fixed in:** 6.0.1 [RTI Issue ID CORE-9306] .. _section-xml-compatibility-alphanumeric: XSD validation fails if topic_ref or register_type_ref uses some non-alphanumeric characters ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ XSD validation of an XML application creation file now fails if there are |DW| ``topic_ref`` and ``register_type_ref`` attributes using non-alphanumeric characters such as '#'. The only strings allowed are those matching this pattern: .. code-block:: bash ((::)?[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 ```` tag, which is available in both ```` and ```` tags. For example: .. code-block:: xml ... ... com/rti/example/MyTopic ... ... This problem has been fixed to allow the non-alphanumeric characters. **Fixed in:** 6.0.1 [RTI Issue ID CORE-9484] .. _section-frag-error: Dynamic Data issues ------------------- .. _section-9653: Segmentation fault when using unkeyed DynamicData |DR| with content filter and writer-side filtering ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A |DR| may receive samples that do not match the content filter being used by the |DR|, even if the |DW| is performing writer-side filtering. This could happen for two reasons: * The |DR| changes its filter after the |DW| writes the sample, and the sample passes the |DR|'s previous filter. * There is another |DR| at the same locator that should receive the sample. An unkeyed DynamicData |DR| that receives a sample due to the second reason above may segfault while attempting to return the sample resources after dropping the filtered sample. **Fixed in:** 6.0.1 [RTI Issue ID CORE-9653] Invalid serialization of samples with types containing primitive members that require padding ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ See more information in :numref:`section-codegen-serialize-sample`. .. _section-9821: Possible data corruption or crash when using DynamicData and a type with inheritance ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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: .. code-block:: text struct ComplexMember { string myString; }; struct BaseType { sequence myComplexSequence; }; struct DerivedType : BaseType { long myLong; }; **Fixed in:** 6.0.1 [RTI Issue ID CORE-9821] .. _section-9832: Missing parameter checking for several DynamicData APIs results in segmentation faults or incorrect return codes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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. **Fixed in:** 6.0.1 [RTI Issue ID CORE-9832] .. _section-9685: Binding to unset optional member causes some operations on parent DynamicData object to fail ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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. **Fixed in:** 6.0.1 [RTI Issue ID CORE-9685] .. _section-9872: Discovery does not complete, and there is no error -------------------------------------------------- In 5.3.1 and below, |DP| 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: .. code-block:: text 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 |DW|. Additionally, since the builtin ParticipantBuiltinTopicData |DR| 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. .. note:: When |DP| 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 |DP| announcements. **Fixed in:** 6.0.1 [RTI Issue ID CORE-9872] .. _section-qos-crash: Crash when deserialized_type_object_dynamic_allocation_threshold set to 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. **Fixed in:** 6.0.1 [RTI Issue ID CORE-9532] .. _section-9232: .. |dw.get_matched_sub| replace:: DDS::DataWriter::get_matched_subscription_data .. |dr.get_matched_pub| replace:: DDS::DataReader::get_matched_publication_data Wrong return code for |dw.get_matched_sub| and |dr.get_matched_pub| ------------------------------------------------------------------- ``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). **Fixed in:** 6.0.1 [RTI Issue ID CORE-9232] .. _section-coherent-set-bug: DataReader reports incorrect sample lost and rejected when receiving coherent set --------------------------------------------------------------------------------- There is an issue that provokes |DRs| 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: .. code-block:: text PRESCstReaderCollator_addCollatorEntryToPolled:!assert instance PRESCstReaderCollator_assertInstance:!keyhash not available, dropping the sample... **Fixed in:** 6.0.1 [RTI Issue ID CORE-9576] .. _section-qos-incorrect: QoS policies not resolved to correct values ------------------------------------------- The implementation of Qos Profile composition (see “XML multiple inheritance” in :link_connext_whats_new_600:`What's New in 6.0.0 <>`) introduced a regression. Consider this example: .. code-block:: xml In this example, "DW_IncorrectValues" points to "Parent," which is not a ```` but a ````. Therefore, |CONNEXT| should inherit values from the following elements, in order: #. BuiltinQosLibExp::Generic.StrictReliable (and its parents, and their parents if any) #. 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 ```` points directly to another ```` and not a ````. In this example, you would make the following correction: .. code-block:: xml 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 ```` contains an having its own ``base_name`` attribute value, |CONNEXT| will find and return the correct QoS values. For more information on QoS Profile Inheritance, see :link_connext_inherit_usersman_601:`the "QoS Profile Inheritance" section in the RTI Connext DDS Core Libraries User's Manual <>`. **Fixed in:** 6.0.1 [RTI Issue ID CORE-9376] |RTI_SP_PRODUCT_HEADING| ======================== .. _section-security-2170: Discovery time scales poorly ---------------------------- In 6.0.0, endpoint discovery time scales poorly as the number of endpoints increased. Moreover, when using the |LIGHT_SP_BUILTIN| or the |SP_BUILTIN| running under *HMAC-Only mode*, participant discovery time incorrectly does not scale as the number of participants increased. **Fixed in:** 7.2.0 [RTI Issue ID SEC-2170] .. _section-security-911: Possible lack of SUBSCRIPTION_MATCHED_STATUS if a DataWriter loses liveliness with the DataReader ------------------------------------------------------------------------------------------------- There is a race condition in which a |DR| may never report a SUBSCRIPTION_MATCHED_STATUS change despite successfully matching and receiving data from a |DW|. This race condition occurs if all of the following conditions are true: * The |DR| sets its liveliness ``lease_duration`` to a very small duration (on the order of milliseconds). * The |DR| is communicating with a |DW| with ``metadata_protection_kind`` or ``data_protection_kind`` set to a value other than NONE. * The |DW| loses liveliness with the |DR| between the time the |DR| discovers the |DW| and the time the |DR| receives key material from the |DW|. * The |DW| regains liveliness with the |DR| before the |DR| receives key material from the |DW|. .. note:: This condition is the opposite of the fourth condition in RTI Issue ID SEC-895, which is fixed in 6.0.0. (See :link_connext_sec_fix_other_release_notes_600:`What's Fixed in 6.0.0 <>` in the |SP_RN|.) **Fixed in:** 6.0.1 [RTI Issue ID SEC-911] .. _section-security-1031: Applications directly calling OpenSSL APIs after DomainParticipant deletion may crash ------------------------------------------------------------------------------------- The destruction of all the |DPs| loading |RTI_SP_PRODUCT| 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. **Fixed in:** 6.0.1 [RTI Issue ID SEC-1031] .. _section-security-1013: |DW| does not report PUBLICATION_MATCHED_STATUS for |DRs| that are inactive when it receives their key material --------------------------------------------------------------------------------------------------------------- Under the following sequence of events, a |DW| setting ```` or ```` to a value other than NONE never reports PUBLICATION_MATCHED_STATUS for a |DR|: #. The |DW| discovers the |DR|. #. The |DR| 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). #. The |DW| receives key material from the |DR|. #. The |DR| becomes active after starting to respond to HBs and/or making progress on the NACK messages. #. The |DW| incorrectly does not report PUBLICATION_MATCHED_STATUS for a |DR|. **Fixed in:** 6.0.1 [RTI Issue ID SEC-1013] .. _section-codegen-regressions: Code Generator ============== .. _section-CODEGENII-1489: 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 :numref:`section-Codegen-Opt`), 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: .. code-block:: omg-idl typedef long MyLong; struct MyStruct { MyLong m1; } The C output with ``-optimization`` 1 or 2 would be as follows: .. code-block:: C struct MyStruct { int m1; } The C output with ``-optimization`` 0 would be as follows: .. code-block:: C 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: .. code-block:: omg-idl typedef string<128> MyBoundedString; struct MyStruct { sequence m1; } The C output with ``-optimization`` 0 would be as follows: .. code-block:: C struct MyStruct { MyBoundedStringSeq m1; } The C output with ``-optimization`` 1 or 2 would be as follows: .. code-block:: C 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. **Fixed in:** 6.1.1 [RTI Issue ID CODEGENII-1489] Invalid key deserialization for mutable derived types with key members ---------------------------------------------------------------------- See :ref:`section-CORE-11378` above. Malformed samples with invalid strings not dropped by DataReader in C, traditional C++, and modern C++ ------------------------------------------------------------------------------------------------------ See :ref:`section-CORE-11203` above. .. _section-codegen-serialize-sample: Invalid serialization of samples with types containing primitive members that require padding --------------------------------------------------------------------------------------------- Serialization of samples with a type containing a nested complex type with primitive members that require padding may fail. This means that a |DR| may receive an invalid value for a sample. Example: .. code-block:: text @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. **Fixed in:** 6.0.1 [RTI Issue IDs CODEGENII-1196 and CORE-9777] .. _section-codegen-serialize-java: Java exception during serialization/deserialization of keyed types whose key is an unkeyed nested type with unbounded members ----------------------------------------------------------------------------------------------------------------------------- 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: .. code-block:: text @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. **Fixed in:** 6.0.1 [RTI Issue ID CODEGENII-1194] .. _section-codegen-1208: Incorrect deserialization in .Net of samples from certain types when published from a writer with disable_inline_keyhash set to true ------------------------------------------------------------------------------------------------------------------------------------ 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 |DW|, 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. .. code-block:: text 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: .. code-block:: text 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 **Fixed in:** 6.0.1 [RTI Issue ID CODEGENII-1208] Generated code in traditional C++ with namespaces for an IDL containing a nested module called "rti" will not compile --------------------------------------------------------------------------------------------------------------------- The generated code for traditional C++ does not compile if a module is called "rti" and the code is generated with ``-namespace``. For example: .. code-block:: text module com { module rti { struct Foo { long m1; }; }; }; You will see errors like the following one: .. code-block:: text 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< **Fixed in:** 6.0.1 [RTI Issue ID CODEGENII-1099] Routing Service =============== .. _ROUTING-1257: Vulnerability: Potential stack corruption in Routing Service when using malicious XML configuration document ------------------------------------------------------------------------------------------------------------ An out-of-bounds write on the stack in *Routing Service* may occur after loading a malicious XML QoS document. **User Impact without Security** A vulnerability in *Routing Service* while loading configurations via XML could result in the following: - *Routing Service* could corrupt the stack. - Exploitable by providing a malicious XML document to *Routing Service* during startup or via remote administration. - Potential impact on the integrity of *Routing Service* when using the XML QoS document. - Potential crash in the application. - CVSS v3.1 Base Score: 9.1 CRITICAL. - CVSS v3.1 Vector: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H `__. - CVSS v4.0 Base Score: 8.8 HIGH. - CVSS v4.0 Vector: `CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N `__. **User Impact with Security** A vulnerability in *Routing Service* while loading configurations via XML could result in the following: - *Routing Service* could corrupt the stack. - Exploitable by providing a malicious XML document to *Routing Service* during startup. - Potential impact on the integrity of *Routing Service* when using the XML QoS document. - Potential crash in the application. - A Governance Document with a value other than NONE for a ``*_protection_kind`` that applies to the *Routing Service’s* remote administration topics would defend against any attacks over the network. - CVSS v3.1 Base Score: 7.1 HIGH. - CVSS v3.1 Vector: `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H `__. - CVSS v4.0 Base Score: 6.9 MEDIUM. - CVSS v4.0 Vector: `CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N `__. **Mitigations** - Use the *Security Plugins* RTPS protection to prevent the Network Attack Vector, AND - Restrict permissions for writing to the configuration files *Routing Service* uses, to prevent the Local Attack Vector. **Fixed in:** 7.5.0 [RTI Issue ID ROUTING-1257] .. _section-Product-Routing-unbmem: 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. **Fixed in:** 6.1.1 [RTI Issue ID ROUTING-833] .. _section-Product-Routing-xmlfail: Create method in Service API fails to parse XML snippets that start with 'str://' --------------------------------------------------------------------------------- ``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. **Fixed in:** 6.1.0 [RTI Issue ID ROUTING-606] .. _section-Product-Routing-logqos: Executable ignores logging QoS ------------------------------ Logging settings specified in the ``DomainParticipantFactory`` QoS are ignored when running the shipped |RS| application. (This problem does not occur when you deploy |RS| 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 |RS| application. **Fixed in:** 6.0.1 [RTI Issue ID ROUTING-641] .. _section-Product_Recording-Regress: Recording Service ================= Segmentation fault after discovering application that used UserData QoS Policy ------------------------------------------------------------------------------ If *Recording Service* discovered an application that had at least one entity (|DP|, |DR|, or |DW|) that used the UserData QoS Policy, the behavior was undefined and would likely have resulted in a segmentation fault. **Fixed in:** 6.1.0 [RTI Issue ID RECORD-1125] Legacy deserialized database table cannot be replayed or converted if it contains compact byte sequences or arrays ------------------------------------------------------------------------------------------------------------------ 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: .. code-block:: text struct LargeByteSeqType { sequence 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: .. code-block:: text 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. **Fixed in:** 6.0.1 [RTI Issue ID RECORD-957] Segmentation fault in *Replay Service* or *Converter* if recorded topics have "::" in their names ------------------------------------------------------------------------------------------------- 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. **Fixed in:** 6.0.1 [RTI Issue ID RECORD-959] .. _section-Product_CDS-Regress: Cloud Discovery Service ======================= Cloud Discovery Service executable did not log build ID for DDS libraries ------------------------------------------------------------------------- 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. **Fixed in:** 6.0.1 [RTI Issue ID CDS-51]