4.20. Data Corruption

4.20.1. [Critical] Data corruption in Monitoring Library 2.0 due to race condition during event and log processing

A race condition in Monitoring Library 2.0 could lead to a use-after-free condition, resulting in data corruption.

Monitoring Library 2.0 processes events and log messages asynchronously using multiple internal threads. If a cleanup pass was attempted while another thread was busy processing events or log messages, the cleanup pass was silently skipped. Over time, this could leave stale references to memory that had already been freed.

Once a dangling reference existed, Monitoring Library 2.0 could read or write corrupted data, leading to undefined behavior.

[RTI Issue ID MONITOR-765]

4.20.2. [Major] Monitoring Library 2.0 failed to create dependent Entities when type_object_max_serialized_length and type_code_max_serialized_length were 0 *

Monitoring Library 2.0 did not detect types when type_object_max_serialized_length and type_code_max_serialized_length were set to 0 in the DomainParticipantResourceLimits QoS policy. As a result, all dependent Entities (Topics, DataReaders, and DataWriters) were not created.

Monitoring Library 2.0 now correctly handles types when they are not configured for distribution, and all dependent Entities are created.

[RTI Issue ID MONITOR-744]

4.20.3. [Minor] Converting a GUID_t to a BuitinTopicKey_t had issues when high bit was set

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

The BuiltinTopicKey_t.from_guid() method failed to convert properly if the incoming GUID_t had a byte pattern that set the highest bit in the resulting four-segment number in the conversion.

[RTI Issue ID CORE-15492]

* This bug does not affect you if you are upgrading from 7.3.x or earlier.