9.2. Regressions in 7.3 LTS

The following regressions were introduced in Connext 7.3 LTS.

9.2.1. General

9.2.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 in a major release: may be fixed in a patch; contact support@rti.com.

[RTI Issue ID CORE-15966]

9.2.2. Core Libraries

9.2.2.1. Duplicate network traffic captures when creating WaitSets, AsyncWaitSets, or GuardConditions

Creating WaitSets, AsyncWaitSets, or GuardConditions could cause the same DomainParticipantFactory instance to be added multiple times to an internal global list of all the DomainParticipantFactories in an application. As a result, Network Capture (which uses the global list) may capture traffic from the same DomainParticipants multiple times.

After fixing this problem, the DomainParticipantFactory instance is no longer added multiple times in this case and, consequently, Network Capture no longer captures DomainParticipants’ traffic multiple times.

Fixed in: 7.7.0

[RTI Issue ID CORE-15913]

9.2.2.2. Error when setting QoS on Publisher or Subscriber without endpoints

When changing the Partition QoS Policy of Publishers or Subscribers without endpoints (DataWriters or DataReaders), the operation can unexpectedly fail and log this error:

FAILURE | Notify of group or partition change.

The likelihood of running into this issue increases with the number of Publishers or Subscribers created by your application.

Fixed in: 7.7.0

[RTI Issue ID CORE-15322]

9.2.2.3. Crash on DDS_DomainParticipantFactory_finalize_instance when using XML-Based Application Creation

When using XML-Based Application Creation with multiple registered types, DDS_DomainParticipantFactory_finalize_instance can crash the JVM.

Fixed in: 7.7.0

[RTI Issue ID CORE-14912]

9.2.2.4. Unexpected error messages when disposing of an instance while using batching and setting serialize_key_with_dispose to TRUE

Consider the following DataWriter QoS:

<datawriter_qos>
    <batch>
        <enable>true</enable>
    </batch>
    <protocol>
        <serialize_key_with_dispose>true</serialize_key_with_dispose>
    </protocol>
</datawriter_qos>

The data type is keyed, and the serialized key is not aligned to a 4-byte boundary.

Imagine that DataWriter1 registers an instance, and then DataWriter2 uses the resulting InstanceHandle to write and dispose that instance. DataWriter2 successfully sends one batch with a data sample of a given instance and then attempts to send another batch whose first sample is a dispose message for that same instance.

When using release libraries, DataWriter2 will successfully send the second batch, but the DataReader that is reading the batch from DataWriter2 will experience this error:

ERROR MIGInterpreter_parse:submessage not aligned to 4

When using debug libraries, DataWriter2 will fail to send the batch and will generate this error:

mig.2.0/srcC/generator/Generator.c:1216:RTI0x200003a:!precondition: "!(sample != ((void *)0) && (((sample)->serializedData[encapsulationIndex].serializedData.pointer == ((void *)0) || ((sample)->serializedData[encapsulationIndex].serializedData.length & 0x3) == 0)) && (((sample)->protocolParameters.pointer == ((void *)0) || ((sample)->protocolParameters.length & 0x3) == 0)))

After fixing this problem, DataWriter2 will successfully send the batch, and the DataReader will successfully receive the batch when using either release or debug libraries.

Fixed in: 7.7.0

[RTI Issue ID CORE-15528]

9.2.2.5. RTI DDS Spy shows DDS_DataReader_get_matched_publication_participant_data error before leaking memory

When discovering the deletion of a DataWriter or DataReader immediately after discovering the deletion of the DomainParticipant associated with the DataWriter or DataReader, DDS Spy incorrectly generates these errors before leaking memory:

DDS_DataReader_get_matched_publication_participant_data:ERROR: Failed to get discovered_participant_data
get_matched_publication_participant_data error 4
ERROR DDS_SampleInfoSeq_set_maximum:failed to assert buffer must not be loaned

Fixed in: 7.7.0

[RTI Issue ID CORE-15629]

9.2.2.6. Misleading warning message when one non-loopback interface doesn’t support multicast

If the network interfaces on a machine include an interface that supports multicast and a non-loopback interface that does not support multicast, and you send a multicast packet from the machine, then a warning message like this one will incorrectly appear:

NDDS_Transport_UDP_send:FAILED TO SEND | Message with 64 bytes over 2 interface(s). Total bytes sent: 64. Total bytes to send: 128.

In this example, the multicast packet is 64 bytes, and Connext is incorrectly trying to send it over two interfaces instead of one (hence, the 128). This problem has been fixed by only trying to send the packet over the interface that supports multicast.

Fixed in: 7.7.0

[RTI Issue ID CORE-15833]

9.2.2.7. Incorrect timestamp in log messages with microseconds higher than 500000

The function that prints the timestamp for log messages incorrectly rounds up the seconds value, if the microseconds are higher than 500000. This leads to inconsistent timing in the logging showing the timestamp moving backwards:

[2026-02-11 14:27:19.951264] DEBUG rCo#########Evt
  Mx06:RTIEventActiveGeneratorThread_loop:rCo#########Evt sleeping {00000000,2F80453E}
[2026-02-11 14:27:19.136920] DEBUG rCo#########Evt
  Mx06:RTIEventActiveGeneratorThread_loop:rCoShant####Evt gathering events

In the fix for this issue, the timestamp is displayed properly.

Fixed in: 7.7.0

[RTI Issue ID CORE-16508]

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

[RTI Issue ID CORE-15730]

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

[RTI Issue ID CORE-15545]

9.2.2.10. Possible unbounded memory growth on DataReader of keyed type after failing to match with a remote DataWriter

Consider the following scenario:

• You have a DataReader of a keyed type.

• The DataReader discovers a DataWriter, but the matching process fails somehow (e.g., due to a port collision that generates this error: assertRemoteWriter:!create entryPort).

• The DataReader somehow retries the matching process with the same DataWriter (e.g., due to receiving another discovery announcement for the DataWriter after the DataWriter changes its QoS).

The matching process will fail again and generate this error:

PRESCstReaderCollator_getRemoteWriterQueue:FAILED TO ASSERT | remote writer queue node in list.

Repeated occurrences of this error message are correlated with an unbounded memory growth on the DataReader.

Fixed in: 7.7.0

[RTI Issue ID CORE-15095]

9.2.2.11. Possible crash when creating DomainParticipants concurrently

Creating DomainParticipants concurrently can lead to a crash if during the creation process one of the threads accesses the typecode of the internal builtin types while another thread is initializing it.

Fixed in: 7.7.0

[RTI Issue ID CORE-14764]

9.2.2.12. Memory leaks and errors when using DynamicDataReaders or FlatData DataReaders plus DDS-fragmentation and compression or encryption

When a DynamicDataReader or DataReader using a FlatData type receives a fragmented sample that was either compressed or encrypted, the memory used to store the sample’s serialized data is leaked and errors similar to the following are printed:

FATAL rCo79661##01Rcv [PARSE MESSAGE|0x01016350,0x5A66C0E7,0x8DA940ED:0x80000004
{Entity=DR,MessageKind=DATA_FRAG}|
RECEIVE FROM 0x01018673,0xDB0C9361,0xB2B4181F:0x80000003]
Mx02:/home/user/osapi.1.0/srcC/memory/heap.c:1104:RTI0x2022004:inconsistent
free/alloc: block id 0 being freed with "RTIOsapiHeap_allocateBufferAligned" and
was allocated with "RTIOsapiHeap_unknownFunction"

Fixed in: 7.7.0

[RTI Issue ID CORE-15231]

9.2.2.13. Some properties no longer accept LENGTH_UNLIMITED string as valid value

Some properties, such as dds.data_writer.history.memory_manager.fast_pool.pool_buffer_max_size, can’t be set to the special “unlimited” value using the string “LENGTH_UNLIMITED”. Use “-1” instead.

Fixed in: 7.7.0

[RTI Issue ID CORE-14328]

9.2.2.14. Possible segmentation fault while enabling a DataWriter that enables batching

Consider the following scenario:

• You are using the Java API.

• The DataWriterQos has batch.enable set to true.

Attempting to enable a DataWriter with that QoS occasionally fails with a segmentation fault in the internal function PRESTypePluginDefaultEndpointData_calculateBatchBufferSize().

Fixed in: 7.7.0

[RTI Issue ID CORE-14659]

9.2.2.15. Running out of memory during DomainParticipant creation causes DomainParticipantFactory finalization to hang

During DomainParticipant creation, if the internal function REDAWorkerFactory_createWorker runs out of memory and prints this error:

REDAWorkerFactory_createWorker:no space on heap for array with 1024 elements of size 8 bytes

then DomainParticipant creation will fail. The problem was that when you later tried to finalize the DomainParticipantFactory, this operation would hang and repeatedly print these errors:

REDAWorkerFactory_destroyWorkerEx:!take mutex

Fixed in: 7.7.0

[RTI Issue ID CORE-14962]

9.2.2.16. Unexpected warning during DomainParticipant enablement when locator reachability enabled

If you set the DomainParticipantQos::discovery_config::locator_reachability_lease_duration to a value other than DDS_DURATION_INFINITE, then Connext logs this warning during DomainParticipant enablement:

COMMENDAnonWriterService_assertRemoteReader:The remote reader with GUID 0x00000000,0x00000000,0x00000000:0x00020187 has no addressable locators.

Fixed in: 7.7.0

[RTI Issue ID CORE-15718]

9.2.3. Code Generator

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

[RTI Issue ID CODEGENII-2200]

9.2.3.2. Using //@resolve-name false does not avoid resolution when a constant is used as a size for an array, sequence bound, string bound, or wstring bound

When a type is annotated with @resolve-name=false, identifiers within that type—including array bounds—should not be resolved or validated during code generation.

However, Code Generator attempts to validate whether the array bound expression is an integer literal, even when resolution is explicitly disabled. This could lead to unnecessary validation errors and potential code generation failures.

For example:

struct MyType {
    octet data[MY_SIZE_CONST]; //@resolve-name false
};

Fixed in: 7.7.0

[RTI Issue ID CODEGENII-2334]

9.2.4. Admin Console

9.2.4.1. Discovery peer changes not consistently applied or maintained

After editing a DomainParticipant to add or remove discovery peers, the changes might not be applied to future participants on the same domain ID.

As a workaround, remove and re-add the new peer:

1. Click Edit DomainParticipant(s), delete the peer, then click Apply.

2. Click Edit DomainParticipant(s), re-add the new peer, then click Apply.

Fixed in: 7.7.0

[RTI Issue ID ADMINCONSOLE-1450]

9.2.5. Security Plugins

9.2.5.1. Potential stack buffer read overflow in Builtin Security Plugins when registering local endpoint

An application using the Builtin Security Plugins may attempt to read invalid memory during the creation of a local secure entity (DomainParticipant, DataWriter, or DataReader). This can result in a segmentation fault. As a result of reading invalid data, there is also a low chance of a discovery incompatibility due to a mismatch of security algorithms.

Fixed in: 7.7.0

[RTI Issue ID SEC-2849]

9.2.5.2. Potential segmentation fault in Builtin Security Plugins when discovering a DomainParticipant

Assume that in the Governance Document, at least one protection_kind field, other than rtps_protection_kind, is set to a value other than NONE. When one DomainParticipant is discovering another, there is a race condition leading to a NULL pointer dereference in the internal function RTI_Security_Cryptography_registerEndpoint.

Fixed in: 7.7.0

[RTI Issue ID SEC-2913]

9.2.5.3. Segmentation fault in Java while enabling a DataWriter that protects payloads and enables batching

Consider the following scenario:

• You are using the Java API.

• The Governance Document has <data_protection_kind> set to a value other than NONE for a given topic.

• The DataWriterQos has batch.enable set to true.

Attempting to enable a DataWriter of that topic and with that QoS fails with a segmentation fault in the internal function PRESTypePluginDefaultEndpointData_calculateBatchBufferSize.

Fixed in: 7.7.0

[RTI Issue ID SEC-2457]

9.2.6. Routing Service

9.2.6.1. Unexpected error messages when Routing Service disposes of an instance while using batching and setting serialize_key_with_dispose to TRUE

Consider the following Routing Service writer QoS:

<datawriter_qos>
    <batch>
        <enable>true</enable>
    </batch>
    <protocol>
        <serialize_key_with_dispose>true</serialize_key_with_dispose>
    </protocol>
</datawriter_qos>

The data type is keyed, and the serialized key is not aligned to a 4-byte boundary.

Imagine that Routing Service successfully sends one batch with a data sample of a given instance and then attempts to send another batch whose first sample is a dispose message for that same instance.

When using release libraries, Routing Service will successfully send the second batch, but the DataReader that is reading the batch from Routing Service will experience this error:

ERROR MIGInterpreter_parse:submessage not aligned to 4

When using debug libraries, Routing Service will fail to send the batch and will generate this error:

mig.2.0/srcC/generator/Generator.c:1216:RTI0x200003a:!precondition: "!(sample != ((void *)0) && (((sample)->serializedData[encapsulationIndex].serializedData.pointer == ((void *)0) || ((sample)->serializedData[encapsulationIndex].serializedData.length & 0x3) == 0)) && (((sample)->protocolParameters.pointer == ((void *)0) || ((sample)->protocolParameters.length & 0x3) == 0)))

After fixing this problem, Routing Service will successfully send the batch, and the DataReader will successfully receive the batch when using either release or debug libraries.

Fixed in: 7.7.0

[RTI Issue ID ROUTING-1288]