.. include:: /../getting_started/vars.rst

.. _section-Regressions:


Regressions in 6.0.0
********************

The following regressions are introduced in 6.0.0; most are 
fixed in later releases. Issues that are fixed are clearly indicated.

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


Fixed in 7.0.0
--------------

.. _CORE-12352:

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 release 7.0.0.

[RTI Issue ID CORE-12352]



Fixed in 6.1.1
--------------

.. _section-xml-compatibility-publisher:

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:

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

    <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:

.. code-block:: xml

    <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]


.. _section-CORE-11378:

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:

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

This problem has been resolved in release 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++
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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]


Fixed in 6.1.0
--------------

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]


Fixed in 6.0.1
--------------

.. _section-xml-compatibility:

XSD issues
^^^^^^^^^^

.. _section-9306:

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:

.. code-block:: xml

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

This problem is fixed in release 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
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
In 6.0.0, 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  
``<registered_name>`` tag, which is available in both ``<register_type>`` and ``<topic>`` tags. 
For example:

.. code-block:: xml

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


.. _section-frag-error:


Dynamic Data issues
^^^^^^^^^^^^^^^^^^^

.. _section-9653:

Segmentation fault when using unkeyed DynamicData |DR| with content filter and writer-side filtering
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
In 6.0.0, 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.

This problem is fixed in release 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
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
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:

.. code-block:: text

    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]


.. _section-9832:

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]


.. _section-9685:

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]


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

This problem is fixed in release 6.0.1.

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

[RTI Issue ID CORE-9872]


.. _section-qos-crash:

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]


.. _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|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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]



.. _section-coherent-set-bug:

DataReader reports incorrect sample lost and rejected when receiving coherent set
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In 6.0.0, 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...

This problem is fixed in release 6.0.1.

[RTI Issue ID CORE-9576]


.. _section-qos-incorrect:

QoS policies not resolved to correct values
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In 6.0.0, 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

    <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:

#. 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 ``<xxx_qos>`` points directly to another ``<xxx_qos>`` 
and not a ``<qos_profile>``. In this example, you would make the following correction:

.. code-block:: xml

    <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 
:link_connext_inherit_usersman_601:`the "QoS Profile Inheritance" section in the RTI Connext DDS Core Libraries User's Manual <>`.

[RTI Issue ID CORE-9376]


RTI Security Plugins
====================

Fixed in 6.0.1
--------------

.. _section-security-911:

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 |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 Security Plugins Release Notes <>`.)

This problem is fixed in release 6.0.1.

[RTI Issue ID SEC-911]


.. _section-security-1031:

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]



.. _section-security-1013:

|DW| does not report PUBLICATION_MATCHED_STATUS for |DRs| that are inactive when it receives their key material
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In 6.0.0, under the following sequence of events, a |DW| setting ``<metadata_protection_kind>`` 
or ``<data_protection_kind>`` 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|.

This problem is fixed in release 6.0.1.

[RTI Issue ID SEC-1013]


.. _section-codegen-regressions:

RTI Code Generator
==================

Fixed in 6.1.1
--------------

.. _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<MyBoundedString> 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. The problem is fixed in release 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.


Fixed in 6.0.1
--------------

.. _section-codegen-serialize-sample:

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

This problem is fixed in release 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 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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:

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

This problem is fixed in release 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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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 |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

This problem is fixed in release 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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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:

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

This problem is fixed in release 6.0.1.

[RTI Issue ID CODEGENII-1099]



RTI Routing Service 
===================

Fixed in 6.1.1
--------------

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

This problem is fixed in release 6.1.1.

[RTI Issue ID ROUTING-833]


Fixed in 6.1.0
--------------

.. _section-Product-Routing-xmlfail:

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]


Fixed in 6.0.1
--------------

.. _section-Product-Routing-logqos:

Executable ignores logging QoS
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In 6.0.0, 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.

This problem is fixed in release 6.0.1.

[RTI Issue ID ROUTING-641]


.. _section-Product_Recording-Regress:

RTI Recording Service 
=====================

Fixed in 6.0.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:

.. code-block:: text

    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:

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

This issue is fixed in release 6.0.1.

[RTI Issue ID RECORD-957]


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]


.. _section-Product_CDS-Regress:

RTI Cloud Discovery Service 
===========================

Fixed in 6.0.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]