10.4. Regressions in 7.2.0

The following regressions were introduced in Connext 7.2.0.

10.4.1. General

10.4.1.1. Running scripts under $NDDSHOME/bin creates two processes

When you run a script located in $NDDSHOME/bin, such as rtirecordingservice, two distinct processes are created: one for the RTI script itself, and another for the application binary executed by the script.

As a workaround, run the platform-specific executable directly. For details, contact support@rti.com.

Not fixed yet

[RTI Issue ID CORE-15966]

10.4.2. Core Libraries

10.4.2.1. Vulnerability: Potential invalid read memory access in Connext applications when subscribing to PublicationBuiltinTopicData

An invalid read memory access in Connext applications can occur after calling DDS_Subscriber_lookup_datareader to retrieve the builtin publication information and then discovering a DataWriter.

User Impact without Security: A vulnerability in Connext applications while discovering a DataWriter can result in the following:

• Out-of-bounds read while parsing a malicious RTPS message.

• Remotely exploitable.

• Potential impact on the confidentiality of Connext applications.

• Potential crash in the application.

• CVSS v3.1 Base Score: 9.1 CRITICAL

• CVSS v3.1 Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H

• CVSS v4.0 Base Score: 8.3 HIGH

• CVSS v4.0 Vector: AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:H/SC:N/SI:N/SA:N

User Impact with Security: There is no impact when enabling certain Connext Security features; see Mitigations for more information.

Mitigations:

• Use Security Plugins RTPS protection, discovery protection, or RTPS PSK protection.

• Set verbosity to NDDS_CONFIG_LOG_VERBOSITY_WARNING or higher for the NDDS_CONFIG_LOG_CATEGORY_API category.

Fixed in: 7.6.0

[RTI Issue ID CORE-15730]

10.4.2.2. Incorrect value of an infinite duration in non-Java APIs

In all language APIs other than Java, the value of an infinite duration (e.g., dds::core::Duration::infinite() in Modern C++) is not compliant with the OMG DDS Specification. The incorrect value is sec = 0x7fffffff, nanosec = 0xffffffff. The correct value is sec = 0x7fffffff, nanosec = 0x7fffffff.

Fixed in: 7.6.0

[RTI Issue ID CORE-15545]

10.4.2.3. Sentinel constant for “invalid” Time contained unexpected value

The sentinel Time value that indicates an “invalid” timestamp is incorrect and doesn’t match the value of an “invalid” SampleInfo::source_timestamp (which can be returned when an instance state is NOT_ALIVE_NO_WRITERS). This makes a comparison such as the following to never be true:

if (info.source_timestamp() == Time::invalid()) {} // never true due to this bug

Starting in 7.3.0, Time::invalid() contains the expected sentinel value.

Fixed in: 7.3.0

[RTI Issue ID CORE-14334]

10.4.2.4. Error message printed for each filtered sample when using writer-side filtering, FlatData, and Zero Copy over shared memory

When using FlatData, Zero Copy over shared memory, and writer-side filtering, every sample that is filtered incorrectly causes an error similar to the following to be logged:

ERROR [0x0101501F,0x044D6680,0xBF657AAB:0x80000002{Entity=DW,Topic=Example
CameraImage,Type=CameraImage,Domain=0}|WRITE]
REDAThresholdBufferPool_returnBuffer:!attempting to return a buffer to a
pool that it was not allocated from.

There is no impact on functionality; the samples are still filtered correctly.

Fixed in: 7.3.0

[RTI Issue ID CORE-14144]

10.4.2.5. RTI Monitor unable to start due to missing nddsjava.jar in rti_connext_dds-7.2.0/lib/java in LM bundles

The nddsjava.jar file is missing in rti_connext_dds-7.2.0/lib/java, making RTI Monitor unable to start. You can work around this issue manually by copying nddsjava.jar from rti_connext_dds-7.2.0/lib/java to rti_connext_dds-7.2.0/resource/app/lib/java. This issue only affects LM bundles and is fixed in 7.3.0. It was also fixed in 7.2.0 shortly after 7.2.0’s initial release.

Fixed in: 7.2.0, 7.3.0

[RTI Issue ID INSTALL-977]

10.4.3. Code Generator

10.4.3.1. Code generation fails if @verbatim annotation encountered

Code Generator (rtiddsgen) is supposed to ignore the @verbatim annotation. However, a bug in Code Generator 4.2.0 (Connext 7.2.0) causes rtiddsgen to fail when it finds @verbatim.

Fixed in: 7.5.0

[RTI Issue ID CODEGENII-2200]

10.4.3.2. Erroneous warning when using -enableEscapeChar

If you use an identifier that is an IDL keyword, you will see an error (for case-sensitive matches) or a warning (for case-insensitive ones). For this reason, Code Generator has the -enableEscapeChar command-line option, which allows you to escape the IDL keywords with an underscore so that they can be used in the IDL.

In release 7.2.0, RTI introduced a feature that incorrectly warns you (or causes Code Generator to fail if you use -strict) when your identifier collides with an IDL keyword, even though you escape the identifier and use -enableEscapeChar.

In the fix for this issue, you will no longer get any warning (or failure if you use -strict) when you escape an identifier that is an IDL keyword.

Fixed in: 7.3.0

[RTI Issue ID CODEGENII-2008]

10.4.3.3. Constant string defined in IDLs/XMLs may cause compilation issues if compiler set to use C++17 standard

rtiddsgen-generated code uses macros to define constants in different ways depending on the C++ standard. The following IDL code:

const string  TEST = "Hello world"

generates

RTI_CONSTEXPR_OR_CONST_STRING std::string TEST = "Hello world";

Depending on the capabilities of the compiler, RTI_CONSTEXPR_OR_CONST_STRING might be expanded as constexpr, in which case the expanded code is:

constexpr std::string TEST = "Hello world";

which is not supported in the C++17 standard.

In the fix for this issue, rtiddsgen no longer generates constexpr std::string.

Fixed in: 7.3.0

[RTI Issue ID CODEGENII-1964]

10.4.4. Security Plugins

10.4.4.1. Verbosity of security-related messages is per application

The last DomainParticipant explicitly setting the plugin-specific logging.verbosity property (set by you, in the QoS settings) will apply that setting to all the DomainParticipants within the application and all security-related messages logged from the Connext libraries. This is the behavior in all Connext releases, except for 7.2.0.

Connext 7.2.0 introduced support for running a combination of DomainParticipants from the Builtin Security Plugins library (nddssecurity) and the Lightweight Builtin Security Plugins library (nddslightweightsecurity) inside the same application. In 7.2.0, the logging verbosity (for all security-related messages) of all the DomainParticipants belonging to the same security library is determined by the last DomainParticipant of that library (as opposed to the last DomainParticipant within the application) that your application creates.

Connext 7.3.0 reverts this behavior. In 7.3.0, the logging verbosity for all security-related messages is again determined by the last DomainParticipant that your application creates.

Fixed in: 7.3.0

[RTI Issue ID SEC-2368]

10.4.4.2. Memory leak when running Security Plugins SDK tester

Running a Security Plugins tester (AccessControlTester, CryptographyTester, or LightweightTester) causes a memory leak, because the testers don’t finalize the DomainParticipantFactory. This issue has been fixed. Now, the testers call DDS_DomainParticipantFactory_finalize_instance() upon finalization.

Fixed in: 7.3.0

[RTI Issue ID SEC-2279]

10.4.4.3. Wrong default Governance configuration for legacy Builtin Secure Logging topic

The Governance configuration for the DDS:Security:LogTopic legacy builtin topic is wrong in Security Plugins 7.2.0 by default. This issue prevents DDS:Security:LogTopic DataReaders from being interoperable with previous versions of Connext and with other vendors. The workaround is to manually configure the topic-level security attributes in the Governance Document:

<topic_rule>
    <topic_expression>DDS:Security:LogTopic</topic_expression>
    <enable_discovery_protection>false</enable_discovery_protection>
    <enable_liveliness_protection>false</enable_liveliness_protection>
    <enable_read_access_control>true</enable_read_access_control>
    <enable_write_access_control>false</enable_write_access_control>
    <metadata_protection_kind>SIGN</metadata_protection_kind>
    <data_protection_kind>ENCRYPT</data_protection_kind>
</topic_rule>

This issue is fixed in 7.3.0. Starting in 7.3.0, there is no need to configure the builtin logging topic security attributes in the Governance Document; subscriptions to both the legacy and non-legacy builtin logging topics work by default.

Fixed in: 7.3.0

[RTI Issue ID SEC-2278]