10.10. Regressions in 6.0.0
The following regressions were introduced in Connext 6.0.0.
10.10.1. Core Libraries
Issues in the Core Libraries may affect components that use these libraries, including services and tools.
10.10.1.1. Non-Java register_type fails if the maximum size is greater than 2 GB
If a data type’s maximum serialized size is greater than 2 GB, then the DomainParticipant
register_type API fails with errors such as these:
RTIXCdrInterpreter_getSerSampleMaxSize:<type>:<field> skip error
RTIXCdrInterpreter_generateTypePluginProgram:failure generating get_max_serialized_size program for type
DDS_DomainParticipant_register_type:!failed to register user type with participant
This problem affects all language APIs except for Java. This problem has been fixed by making this API succeed under this circumstance. Connext supports registering types whose theoretical maximum serialized size is greater than 2 GB, as long as the samples that are written are never greater than 2 GB.
Fixed in: 7.6.0
[RTI Issue ID CORE-12308]
10.10.1.2. 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, DataReaders from releases before 6.0.0 may encounter deserialization failures when receiving samples from a DataWriter 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]
10.10.1.3. 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]
10.10.1.4. 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]
10.10.1.5. 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]
10.10.1.6. 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_StatusMaskother thanDDS_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]
10.10.1.7. Application using Monitoring Libraries produces segmentation fault during DataReader creation
An application using the Monitoring Library might produce a segmentation fault during DataReader creation. The issue is very rare and only occurs if a DataReader receives a sample immediately after being enabled.
Fixed in: 6.1.2, 7.1.0
[RTI Issue ID MONITOR-429]
10.10.1.8. 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]
10.10.1.9. Unbounded memory growth in Spy when discovering multiple endpoints with the same Topics and types
Each time DDS Spy discovers an endpoint, it unnecessarily makes a copy of the TypeCode that is associated with the endpoint’s Topic, leading to unbounded memory growth.
Fixed in: 6.1.2, 7.0.0
[RTI Issue ID CORE-12136]
10.10.1.10. Types Containing Typedefs sent without the typedefs in discovery when using DynamicData
When an application uses a DynamicDataReader or DynamicDataWriter and a type that contains a typedef, the type that is sent during endpoint discovery for that endpoint does not contain the typedef. While this does not cause any mismatches or communication failure, it does cause a number of issues that may be noticeable depending on what other products you may also be using. See the release notes descriptions for ADMINCONSOLE-997, ROUTING-971, and CORE-12136 for more details about the specific issues that you may encounter.
In the fix for this issue, the exact type definition that is registered with the DomainParticipant and that contains typedefs is now sent during discovery. This is a change in behavior from 6.0.0-based applications, which send the type definitions without the typedef information.
Fixed in: 6.1.2, 7.0.0
[RTI Issue ID CORE-12107]
10.10.1.11. XSD issue: order enforced in <publisher> 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 <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>
Fixed in: 6.1.1
[RTI Issue ID CORE-9374]
10.10.1.12. 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 is invalid. For example:
@mutable struct Base1 { long m1; }; @mutable struct Derived1 : Base1 { @key long m2; };
This issue affects the following functionality:
Calling the APIs
DataWriter::get_key_valueandDataReader::get_key_valuereturns an invalid value.When
writer_qos.protocol.serialize_key_with_disposeis set toTRUE(not the default value) andwriter_qos.protocol.disable_inline_keyhashis set toTRUE(not the default value), the keyhash calculated on the DataReader for a dispose sample sent by a DataWriter is invalid. This leads to a situation in which a disposed instance is not reported as such on the DataReader side.
This issue affects all language bindings except Java and the legacy .NET API. It also affects DynamicData.
Fixed in: 6.1.1
[RTI Issue ID CORE-11378]
10.10.1.13. Malformed samples with invalid strings not dropped by DataReader in C, traditional C++, and modern C++
A DataReader might provide the application a malformed sample containing an invalid value (not null-terminated) for a string member. The string member might not be null-terminated, resulting in undefined behavior if the application tries to access it.
In the fix for this issue, 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]
10.10.1.15. Serialization of string members does not check for null-terminated strings in C, traditional C++, and modern C++
The code executed by a DataWriter that serializes string members in a Topic type does not check that the strings are null-terminated. This may lead to undefined behavior, because the serialization code calls strlen.
In the fix for this issue, the serialization code checks for null-terminated strings with the maximum allowed length and reports the following error if the string is not well-formed:
RTIXCdrInterpreter_serializeString:StrStruct:member2 serialization error. String length (at least 6) is larger than maximum 5
Fixed in: 6.1.1
[RTI Issue ID CORE-11164]
10.10.1.17. 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]
10.10.1.18. XSD issues
10.10.1.18.1. Order enforced in <domain_participant> 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 <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.
Fixed in: 6.0.1
[RTI Issue ID CORE-9306]
10.10.1.18.2. 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 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 has been fixed to allow the non-alphanumeric characters.
Fixed in: 6.0.1
[RTI Issue ID CORE-9484]
10.10.1.19. Dynamic Data issues
10.10.1.19.1. Segmentation fault when using unkeyed DynamicData DataReader with content filter and writer-side filtering
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.
Fixed in: 6.0.1
[RTI Issue ID CORE-9653]
10.10.1.19.2. Invalid serialization of samples with types containing primitive members that require padding
See more information in Section 10.10.3.5.
10.10.1.19.3. 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:
struct ComplexMember {
string myString;
};
struct BaseType {
sequence<ComplexMember> myComplexSequence;
};
struct DerivedType : BaseType {
long myLong;
};
Fixed in: 6.0.1
[RTI Issue ID CORE-9821]
10.10.1.19.4. 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_typeDynamicDataTypeSupport::get_data_typeDynamicDataTypeSupport::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]
10.10.1.19.5. 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]
10.10.1.20. 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.
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.
Fixed in: 6.0.1
[RTI Issue ID CORE-9872]
10.10.1.21. 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) might crash if
endpoint_type_object_lb_serialization_threshold in the
DomainParticipantQos’s DISCOVERY_CONFIG QosPolicy is set to a value other
than -1.
Fixed in: 6.0.1
[RTI Issue ID CORE-9532]
10.10.1.22. Wrong return code for DDS::DataWriter::get_matched_subscription_data and DDS::DataReader::get_matched_publication_data
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]
10.10.1.23. DataReader reports incorrect sample lost and rejected when receiving coherent set
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...
Fixed in: 6.0.1
[RTI Issue ID CORE-9576]
10.10.1.24. QoS policies not resolved to correct values
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:
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:
<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.
Fixed in: 6.0.1
[RTI Issue ID CORE-9376]
10.10.2. Security Plugins
10.10.2.1. Discovery time scales poorly
In 6.0.0, endpoint discovery time scales 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 does not scale as the number of participants increases.
Fixed in: 7.2.0
[RTI Issue ID SEC-2170]
10.10.2.2. Possible lack of SUBSCRIPTION_MATCHED_STATUS if a DataWriter loses liveliness with the DataReader
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_durationto a very small duration (on the order of milliseconds).The DataReader is communicating with a DataWriter with
metadata_protection_kindordata_protection_kindset 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.)
Fixed in: 6.0.1
[RTI Issue ID SEC-911]
10.10.2.3. Applications directly calling OpenSSL APIs after DomainParticipant deletion may crash
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.
Fixed in: 6.0.1
[RTI Issue ID SEC-1031]
10.10.2.4. DataWriter does not report PUBLICATION_MATCHED_STATUS for DataReaders that are inactive when it receives their key material
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:
The DataWriter discovers the DataReader.
The DataReader becomes inactive after
writer_qos.protocol.rtps_reliable_writer.max_heartbeat_retriesHeartbeats (HBs) due to the lack of response to HBs (default behavior) or to not making progress on the NACK messages (non default - requires settingwriter_qos.protocol.rtps_reliable_writer.inactivate_nonprogressing_readersto TRUE).The DataWriter receives key material from the DataReader.
The DataReader becomes active after starting to respond to HBs and/or making progress on the NACK messages.
The DataWriter incorrectly does not report PUBLICATION_MATCHED_STATUS for a DataReader.
Fixed in: 6.0.1
[RTI Issue ID SEC-1013]
10.10.3. Code Generator
10.10.3.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 9.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.
Fixed in: 6.1.1
[RTI Issue ID CODEGENII-1489]
10.10.3.2. -d64 flag missing in generated Java makefile for Red Hat Enterprise Linux 8.0
The generated Java® makefile for Red Hat® Enterprise Linux® 8.0
(x64Linux4gcc7.3.0) is missing the flag -d64. This missing flag causes
the compiled code to report an error when executed in a 32-bit environment.
Fixed in: 6.1.1
[RTI Issue ID CODEGENII-1332]
10.10.3.3. Invalid key deserialization for mutable derived types with key members
See Invalid key deserialization for mutable derived types with key members above.
10.10.3.4. Malformed samples with invalid strings not dropped by DataReader in C, traditional C++, and modern C++
10.10.3.5. 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 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.
Fixed in: 6.0.1
[RTI Issue IDs CODEGENII-1196 and CORE-9777]
10.10.3.6. 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:
@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]
10.10.3.7. 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 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
Fixed in: 6.0.1
[RTI Issue ID CODEGENII-1208]
10.10.3.8. 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:
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<
Fixed in: 6.0.1
[RTI Issue ID CODEGENII-1099]
10.10.4. Persistence Service
10.10.4.1. RTICdrTypeCodeUtils_type_has_external_members:!get member error when running Persistence Service
The following error may occur when using Persistence Service:
RTICdrTypeCodeUtils_type_has_external_members:!get member
The error is harmless unless you are using ContentFilteredTopics in some of the DataReaders communicating with Persistence Service. In that case, the evaluation of the filter in Persistence Service may be wrong. Samples that should pass the filter(s) may not pass it, and vice versa.
To work around the problem, you can disable TypeCode as the wire representation by setting the following QoS in the applications communicating with Persistence Service before the Persistence Service database is built:
participant_qos.resource_limits.type_code_max_serialized_length = 0
Fixed in: 6.1.1
[RTI Issue ID PERSISTENCE-219]
10.10.5. Routing Service
10.10.5.1. 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_kindthat 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]
10.10.5.2. 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]
10.10.5.3. Large per-sample memory usage in Routing Service
Routing Service has a large out-of-the-box large memory usage. There are 64k bytes of memory allocated per sample, even if the sample’s maximum serialized size is smaller than that value. This results in a large amount of unnecessary and unused memory allocations.
You can work around this problem by using the
memory_management settings in the Routing Service
configuration. For example:
<memory_management>
<sample_buffer_min_size>1200</sample_buffer_min_size>
</memory_management>
The sample_buffer_min_size sets the size of preallocated buffers
used to pass samples through Routing Service. If more space is needed,
then it is dynamically allocated as samples are received. The
sample_buffer_min_size should be set to a value that is larger than
or equal to the minimum serialized size of a type. If it is set to a
value larger than the maximum serialized size of a type, then the maximum
will be used to allocate the buffers instead of the configured value.
In the fix for this issue, buffers will never be allocated that are larger than the maximum serialized size for a type.
Fixed in: 6.1.1
[RTI Issue ID ROUTING-938]
10.10.5.4. Routing Service remote shell: Adding to initial peers list does not work, possible segmentation fault
Using the Routing Service remote shell, rtirssh, with the
add_peer command to add a peer to a DomainParticipant’s initial
peers list does not work properly.
It may also cause a segmentation fault.
Fixed in: 6.1.1
[RTI Issue ID ROUTING-879]
10.10.5.5. Incorrect content filtering and “RTICdrTypeCodeUtils_type_has_external_members:!get member” error
You may see the following error when using Routing Service:
RTICdrTypeCodeUtils_type_has_external_members:!get member
The error is harmless unless you are using ContentFilteredTopics on some of the DataReaders communicating with Routing Service. In this case, Routing Service might evaluate the filter incorrectly. Samples that should pass the filter(s) may not pass, and vice versa.
Fixed in: 6.1.1
[RTI Issue ID ROUTING-863]
10.10.5.6. 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]
10.10.5.7. Memory leak if malformed configuration file prevents Routing Service creation
Suppose Routing Service attempts to use an XML configuration file that is malformed because of a missing closing quote in the xmlns attribute. For example:
xmlns=<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance>
Routing Service creation correctly fails with an error message containing
RTIXMLUTILSParser_parseFile. However, Routing Service also incorrectly leaks memory in
the same function, RTIXMLUTILSParser_parseFile.
Fixed in: 7.6.0
[RTI Issue ID ROUTING-1324]
10.10.5.8. Executable ignores logging QoS
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.
Fixed in: 6.0.1
[RTI Issue ID ROUTING-641]
10.10.6. Recording Service
10.10.6.1. Segmentation fault after discovering application that uses UserData QoS Policy
If Recording Service discovers an application that has at least one entity (DomainParticipant, DataReader, or DataWriter) that uses the UserData QoS Policy, the behavior is undefined and likely results in a segmentation fault.
Fixed in: 6.1.0
[RTI Issue ID RECORD-1125]
10.10.6.2. Executable does not log build ID for DDS libraries
The executable version of Recording Service does not log the build ID of DDS libraries, no matter which verbosity level is specified. (Previously, the build ID was logged for the warning verbosity.)
Fixed in: 6.1.0
[RTI Issue ID RECORD-1024]
10.10.6.3. 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:
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.
Fixed in: 6.0.1
[RTI Issue ID RECORD-957]
10.10.6.4. 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]
10.10.7. Cloud Discovery Service
10.10.7.1. Cloud Discovery Service executable does not log build ID for DDS libraries
DomainParticipantFactory initialization doesn’t appear anywhere in the logging generated by Cloud Discovery Service for any verbosity level. Cloud Discovery Service prints the ROUTER build ID, but the “Welcome to NDDS” message, NDDS C, and NDDS Core Library build IDs aren’t printed.
Fixed in: 6.0.1
[RTI Issue ID CDS-51]
10.10.8. Queuing Service
10.10.8.1. RTICdrTypeCodeUtils_type_has_external_members:!get member error when running Queuing Service
The following, harmless error may occur when using Queuing Service:
RTICdrTypeCodeUtils_type_has_external_members:!get member
Fixed in: 6.1.2
[RTI Issue ID QUEUEING-720]