4.17. Crashes

4.17.1. [Critical] Possible crash if configuration of Monitoring Library 2.0 was remotely modified while an entity was being destroyed

When using Monitoring Library 2.0, the metrics tracked can be remotely modified at runtime. If the change in the configuration happened at the same time that an entity was being deleted, and the entity was affected by the metrics that changed, a timing issue could trigger an update on the monitoring data from that entity, leading to a crash—for example, if Monitoring Library 2.0 changed the metrics for all DataWriters in a DomainParticipant, and one of those DataWriters was being deleted. Now, the change of the metrics configuration is properly protected with respect to the deletion of entities.

[RTI Issue ID MONITOR-740]

4.17.2. [Critical] Crash when dividing by zero in XML type definition

When defining an invalid constant value in XML—for example, setting a default value to an invalid expression such as 42/0—Connext crashed.

For example:

<dds>
    <type_library name="MyTypes">
          <const name="CONST_LONG" type="int32" value="42/0"/>
          <struct name= "MyStruct">
               <member name="m1" type="int32" default="CONST_LONG"/>
          </struct>
    </type_library>
</dds>

If you attempted to load this XML with:

dds::core::QosProvider qos_provider(xml_file_name);

the following error would occur:

DDS_ExpressionValue_divide:BAD PARAMETER FAILURE | 42LL division by zero.

[RTI Issue ID CORE-16126]

4.17.3. [Critical] DataWriter using Durable Writer History and not using Required Subscription crashed when communicating with a DataReader with a role_name

A DataWriter using Durable Writer History and not using Required Subscriptions crashed when trying to communicate with a DataReader that had configured a role_name in its ENTITY_NAME Qos. Now the communication happens properly between the DataWriter and DataReader.

[RTI Issue ID CORE-16285]

4.17.4. [Critical] Possible crash when deleting an Entity while Monitoring Library 2.0 was enabled

A possible crash or heap corruption error could occur if an Entity deletion failed while Monitoring Library 2.0 was enabled. Subsequent deletion of the same Entity could trigger a double-free.

[RTI Issue ID MONITOR-763]

4.17.5. [Critical] Crash when concurrently modifying QoS profiles with Monitoring QoS policy set in default factory profile

There was a race condition that caused a heap-use-after-free error when multiple threads concurrently accessed or modified QoS profiles using DomainParticipantFactory or QosProvider APIs. This issue occurred only when the Monitoring QoS policy was explicitly set in the DomainParticipantFactory default QoS profile.

[RTI Issue ID CORE-16544]

4.17.6. [Critical] Crash when using DDS_RECOVER_INSTANCE_STATE_CONSISTENCY and multiple writers updating the same instances

A DataReader with ReliabilityQosPolicy::instance_state_consistency_kind set to RECOVER_INSTANCE_STATE_CONSISTENCY may have crashed after recovering liveliness with a DataWriter and then receiving samples from a different DataWriter for the same instances that the first DataWriter was writing.

[RTI Issue ID CORE-16604]

4.17.7. [Critical] Segmentation fault in DataReader that was created disabled when using instance state consistency

Consider the following scenario:

  • A DataReader is created disabled (e.g., because its Subscriber sets SubscriberQos.entity_factory.autoenable_created_entities to false).

  • The DataReader has set DataReaderQos.reliability.instance_state_consistency_kind to RECOVER_INSTANCE_STATE_CONSISTENCY.

  • The DataReader is later enabled.

  • The DataReader discovers and matches with a DataWriter.

  • The DataWriter writes a sample.

  • The DataReader stops matching with the DataWriter (e.g., because the Publisher has changed its PartitionQosPolicy).

  • The DataReader matches with the DataWriter again.

The DataReader would experience a problem in the internal function PRESInstanceStateRequestService_scheduleIstRequestOrDispose. In release libraries, the DataReader would experience a NULL pointer dereference. In debug libraries, the DataReader would generate this error: !precondition: "instanceStateRequestService == ((void *)0)".

[RTI Issue ID CORE-16586]

4.17.8. [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]