5.4.17. Crashes

5.4.17.1. [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.4.17.2. [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.4.17.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.4.17.4. [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.4.17.5. [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.4.17.6. [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.4.17.7. [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.4.17.8. [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.4.17.9. [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.4.17.10. [Major] Possible crash after memory allocation failures

A few cases were found where memory allocation failures were not properly handled. This could have led to null pointer dereferences if memory allocation failed.

[RTI Issue ID CORE-15024]

5.4.17.11. [Major] Using unbounded or very large types with query conditions in Python API could cause crash

If you created a query condition using the Python API and the serialized size of the samples that were evaluated against the query condition were large enough to cause a memory allocation failure, a crash could occur if the memory allocation failure was ignored and you continued to use the DataReader that generated the allocation failure.

[RTI Issue ID CORE-15029]

5.4.17.12. [Major] Segmentation fault if application ran out of memory while generating a log message

If the application ran out of memory while generating a log message, then the application would crash with a segmentation fault in the internal function ADVLOGLogger_destroyMessageQueueElement. This problem only affected releases 6.1.0 and above.

[RTI Issue ID CORE-15432]