5.21. Crashes

5.21.1. [Critical] Potential race conditions in construction or deletion of Requesters and Repliers (C, Traditional C++, C#, and Python)

A race condition may have caused crashes or exceptions when constructing or deleting Requesters and Repliers in the C, Traditional C++, C#, and Python APIs.

These issues were previously fixed as RTI Issue IDs [REQREPLY-127] and [REQREPLY-132] for the Modern C++ and Java APIs.

[RTI Issue ID REQREPLY-133]

5.21.2. [Critical] Possible crash when creating dds.DynamicData.Topic with a listener

A crash in the Python API may have occurred while creating a dds.DynamicData.Topic with a listener. The problem did not occur if the listener was set after creating the topic with set_listener(). This problem did not affect IDL-based topics (dds.Topic).

[RTI Issue ID PY-159]

5.21.3. [Critical] Race condition in RTI Monitoring Library 2.0 caused a crash *

A race condition in RTI Monitoring Library 2.0 caused a segmentation fault in the application being monitored. The likelihood of the race condition occurring was extremely low.

[RTI Issue ID MONITOR-691]

5.21.4. [Critical] Possible crash after a failure to create Monitoring Library 2.0 object *

If RTI Monitoring Library 2.0 was enabled in your application, and something failed while creating the library object (for example, if the Monitoring Library 2.0 internal DDS entities could not be created because of an inconsistent QoS configuration), the system may have crashed.

The crash happened during clean-up after the failure, because some improperly initialized pointers were accessed. Before the crash, you may have seen errors in the RTI_Monitoring_create() function.

To prevent this crash, all the pointers are now initialized to NULL before calling RTI_Monitoring_create(). Note that, depending on how your platform handles pointers initialization, this might or might not be a problem.

[RTI Issue ID MONITOR-668]

5.21.5. [Critical] Modern C++ Distributed Logger may have crashed upon instance finalization *

The Modern C++ Distributed Logger may have produced a crash after calling DistLogger::finalize() when a DomainParticipant had been set by the user. This problem was described as fixed in 7.3.0 (RTI Issue ID DISTLOG-238), but the fix was not complete.

[RTI Issue ID DISTLOG-255]

5.21.6. [Critical] Segmentation fault if Application Kind contained more than 255 characters when calling RTI_DL_DistLogger_getInstance

If the Application Kind contained more than 255 characters, accessing the singleton instance of RTI Distributed Logger by the RTI_DL_DistLogger_getInstance method crashed with a segmentation fault.

[RTI Issue ID DISTLOG-244]

5.21.7. [Critical] Potential stack overflow in Connext applications when parsing XML files with a custom DTD with deeply nested entity references

The Core Libraries XML parser had a third-party dependency on Expat version 2.6.3, which is known to be affected by a publicly disclosed vulnerability. This vulnerability has been fixed by upgrading Expat to the latest stable version, 2.7.1. See the “What’s New” section in this document for more details.

The impact on Connext applications of using the previous version was a stack overflow leading to a crash.

[RTI Issue ID CORE-15661]

5.21.8. [Critical] Crash when writing data on a ContentFilteredTopic in combination with transient durability and delegated reliability

In scenarios where a ContentFilteredTopic was used, and the DataWriter and DataReader were using transient durability and delegated reliability (the delegate_reliability property is set to 1), a call to write() would crash if writer-side filtering was applied.

[RTI Issue ID CORE-15350]

5.21.9. [Critical] Potential crash if creation of Publisher or Subscriber failed while database garbage collection process was running

RTI uses an internal in-memory “database” to store information about entities created locally as well as remote entities found during the discovery process. This database utilizes a background thread that periodically performs garbage collection on records related to deleted entities.

A potential crash could occur due to a race condition if the creation of a Publisher or Subscriber failed while the periodic garbage collection thread was active. Prior to the crash, an error message was logged in the DDS_Subscriber_createI or DDS_Publisher_createI functions.

The probability of encountering this race condition was low.

[RTI Issue ID CORE-15337]

5.21.10. [Critical] Possible crash when calling any write operation on architectures with a weak memory model

On architectures that use a weak memory model, such as Arm-based architectures, the application may have crashed when calling any write operation, FooDataWriter_write(), FooDataWriter_write_w_timestamp or FooDataWriter_write_w_params (or their C++ equivalents). The crash happened in some rare cases due to a reordering of the memory storages.

[RTI Issue ID CORE-15103]

5.21.11. [Critical] Stack smashing error when serializing strings with RTI_CDR_SIZEOF_LONG_DOUBLE set to 16 in C++11 in release mode using GCC compiler

A stack smashing fault occurred when serializing strings if the RTI_CDR_SIZEOF_LONG_DOUBLE configuration was set to 16 in C++11 in release mode using the GCC compiler. Compiling the code reported a warning similar to:

include/ndds/hpp/rti/topic/cdr/InterpreterHelpers.hpp:165:31: note: the ABI of passing union with ‘long double’ has changed in GCC 4.4
  165 |     static RTIXCdrMemberValue get_value_pointer(
      |                               ^~~~~~~~~~~~~~~~~

[RTI Issue ID CORE-14999]

5.21.12. [Critical] Stack overflow when parsing very long SQL filter expressions

If a SQL filter expression contained too many OR/AND expressions in a chain, parsing it may have caused a stack overflow and a program crash. For example:

a=1 OR a=2 OR a=3 OR a4 OR ... OR a=123456

[RTI Issue ID CORE-14985]

5.21.13. [Critical] Crash if element in initial_peers longer than 72 characters added

If a DomainParticipant had an element in the initial_peers longer than 72 characters, or if a peer longer than 72 characters was added using DDS_DomainParticipant_add_peer(), the program would crash. This problem has been resolved, and now peers up to 210 characters in length can be added. If a peer is added that is longer than 210 characters, the program will not crash, but the DomainParticipant will print the following set of errors:

DDS_DiscoveryQosPolicy_parseParticipantPeerDescriptor: locator string too long: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
ERROR [0x010134D9,0x574C97F0,0xE8BB2C8C:0x000001C1{Domain=0}|ADD_PEER BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB] DDS_DiscoveryQosPolicy_parsePeerDescriptorString:peer descriptor  format is unrecognized, string value = "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"
ERROR [0x010134D9,0x574C97F0,0xE8BB2C8C:0x000001C1{Domain=0}|ADD_PEER BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB] DDS_DomainParticipantDiscovery_add_peer:invalid peer descriptor

[RTI Issue ID CORE-14970]

5.21.14. [Critical] Possible crash on MIGInterpreter_parse while receiving data at the same time that entities are removed, on architectures with a weak memory model

On architectures that use a weak memory model, such as Arm or PowerPC, the application may have crashed when receiving data at the same time that the DataReader or a matching DataWriter was being removed. The crash happened on the function MIGInterpreter_parse() in some rare cases, due to a reordering of the memory storages. Now, the crash will not happen; the mentioned API can be called at the same time that a matching entity is removed.

[RTI Issue ID CORE-14923]

5.21.15. [Critical] 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() could have crashed the JVM.

This issue affected Release Libraries, but not Debug Libraries.

[RTI Issue ID CORE-14912]

5.21.16. [Critical] Possible crash when creating DomainParticipants concurrently *

Creating DomainParticipants concurrently could have caused a crash if, during the creation process, one of the threads accessed the typecode of the internal builtin types while another thread was initializing it.

[RTI Issue ID CORE-14764]

5.21.17. [Critical] Possible crash when calling DDS_DataWriter_get_matched_subscriptions() or DDS_DataReader_get_matched_publications() on architectures with a weak memory model

On architectures that use a weak memory model, such as Arm-based architectures, the application may have crashed when calling DDS_DataWriter_get_matched_subscriptions() or DDS_DataReader_get_matched_publications() (or their C++ equivalents) at the same time that a new matching entity was discovered. The crash happened in some rare cases due to a reordering of the memory storages. Now the mentioned APIs can be called at the same time that a new matching entity is discovered.

[RTI Issue ID CORE-14743]

5.21.18. [Critical] 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 would occasionally fail with a segmentation fault in the internal function PRESTypePluginDefaultEndpointData_calculateBatchBufferSize(). This problem only affected releases 7.0.0 to 7.3.0.

[RTI Issue ID CORE-14659]

5.21.19. [Critical] Parsing of malformed RTPS packets may have led to bus error on some platforms

Parsing malformed RTPS packets (with or without RTI Security Plugins) may have caused a bus error on QNX platforms running on an armv7 processor (this may not be the only platform affected). This was fixed and a malformed RTPS message is now dropped before causing the bus error.

[RTI Issue ID CORE-14549]

5.21.20. [Critical] Potential crash when creating new GuardCondition when low on resources

In the Java API, the creation of a new GuardCondition could have led to a crash. This only happened when there was an issue in allocating native resources.

[RTI Issue ID CORE-14544]

5.21.21. [Critical] Segmentation fault when copying invalid samples and using Zero Copy transfer over shared memory transport

When reading or taking samples from a DataReader’s queue, the samples can either be loaned or copied from the queue, depending on which version of the read or take API is used and how it is used. When a DataReader that supported receiving samples over the Zero Copy transfer over shared memory transport used the read or take APIs that copied samples from the DataReader’s queue (instead of loaning them), the application crashed if any of the samples had the SampleInfo::valid_data flag set to false. The only safe APIs for copying samples from the DataReader’s queue were FooDataReader::read_next_sample() and FooDataReader::take_next_sample() because those APIs skip samples with the valid_data flag set to false.

[RTI Issue ID CORE-14442]

5.21.22. [Critical] Parsing an XML file with a root “types” tag that contained a “name” attribute led to a segmentation fault

When Connext parsed an XML file with a root “types” tag, and that tag contained a “name” attribute, a segmentation fault occurred. The use of the name attribute in a root types tag is not permitted by the OMG ‘Extensible and Dynamic Topic Types for DDS’ specification, version 1.3, so this error would only occur with non-conforming XML files. Other non-conforming XML files, such as those with invalid root tags that contained elements with the name attribute, also caused this issue.

[RTI Issue ID CORE-14422]

5.21.23. [Critical] Possible crash when metric value changed when Monitoring Library 2.0 was being disabled *

One of the Monitoring Library 2.0 threads may not have finalized if a metric change happened at the same time that Monitoring Library 2.0 was being disabled. That thread crashed after trying to access memory that was already freed. Now all threads are properly finalized.

[RTI Issue ID MONITOR-735]

5.21.24. [Critical] Segmentation fault and precondition errors with Monitoring Library 2.0 when Entities were deleted *

Applications using Monitoring Library 2.0 could experience a rare segmentation fault when Connext entities (such as DataWriters) were deleted. Additionally, when linking against the Connext debug libraries, you may have observed precondition errors in the log output.

[RTI Issue ID MONITOR-734]

5.21.25. [Critical] Segmentation fault when a DomainParticipant failed to be created

You may have seen a rare segmentation fault if a DomainParticipant failed to be created.

[RTI Issue ID CORE-16045]

5.21.26. [Critical] Segmentation fault when using Network Capture APIs concurrently with DomainParticipantFactory deletion

Calling Network Capture APIs while another thread was deleting the DomainParticipantFactory could cause a segmentation fault due to unsafe concurrent access to internal resources. This issue has been resolved to prevent crashes in such scenarios.

[RTI Issue ID CORE-15914]

5.21.27. [Critical] Potential crash while printing the log message after an error *

Due to mishandled string parameters on some log messages, an application running Connext could crash after an error had already happened. The problematic log messages are now properly generated and printed.

[RTI Issue ID CORE-15862]

5.21.28. [Critical] Possible crash when accessing information about a remote endpoint at the same time that the endpoint was being removed

The application could have crashed if it was trying to access information about a remote endpoint at the same time that the endpoint was being removed. (A remote endpoint is removed when the remote endpoint is deleted or loses liveliness.)

[RTI Issue ID CORE-15297]

5.21.29. [Critical] Possible crash when using QosProvider to load XML file with syntax “file:///” on Windows systems

This issue was fixed in 7.3.0, but not documented at that time.

When using a QosProvider to load profiles from a file, the documented syntax for specifying the file’s URL is to use three slashes: file:///. However, using the file:/// syntax caused a crash on Windows systems. The workaround was to use two slashes, file://)

To address this, both file:/// and file:// are now valid.

[RTI Issue ID CORE-14603]

5.21.30. [Critical] Possible segmentation fault when deleting a DomainParticipant when DNS tracker was enabled

This issue was fixed in 7.0.0, but not documented at that time.

An application may have produced a segmentation fault when a DomainParticipant in which DNS tracker was enabled was deleted.

[RTI Issue ID CORE-14958]

5.21.31. [Major] Possible crash when closing a logger device while it was being used

Due to a concurrency issue in the Connext logging infrastructure, there was the small possibility of a crash in an application when a logger device was closed at the same time it was being used for logging a message.

[RTI Issue ID CORE-10546]

5.21.32. [Major] Precondition added to rti::flat::StringBuilder::set_string() and rti::flat::PrimitiveSequenceBuilder<T>::add_n()

A misuse of the APIs rti::flat::StringBuilder::set_string() or rti::flat::PrimitiveSequenceBuilder<T>::add_n()—specifically, passing nullptr to parameters that expect a valid pointer—can result in a crash.

It is the caller’s responsibility to ensure that these parameters are not null.

When linking against debug libraries, this requirement is now enforced through precondition checks. However, in release mode these checks are omitted to keep FlatData as low-latency as possible, and therefore API misuse will not be detected at runtime.

[RTI Issue ID CORE-16134]

* This bug did not affect you if you are upgrading from 6.1.x or earlier.