4.16. Crashes

4.16.1. Race condition when using multiple threads to enable same DomainParticipant

Suppose you created a disabled DomainParticipant. If you used multiple threads to enable this DomainParticipant, then a race condition may have led to a segmentation fault in release libraries or a precondition error in debug libraries. The precondition error looked similar to this:

REDAWeakReference_getReferent:!precondition: !((reference) != ((void *)0) && (reference)->_manager != ((void *)0) && (reference)->_referentEpochAtCreation != (0)) || tableWithStartedCursor==((void *)0)

RTINetioReceiver_removeEntryport:!goto WR NetioReceiver_Entryport

This problem has been fixed. Calling enable() on a DomainParticipant is now thread-safe with respect to other calls to enable() on the same DomainParticipant.

[RTI Issue ID CORE-13535]

4.16.2. Possible crash gathering periodic metrics for a resource that was being added or deleted at the same time

Due to concurrency issues in the thread that gathers the periodic metrics of the observable resources, an application might have crashed because the thread accessed invalid memory. The crash could occur in any of the following scenarios:

When a resource was deleted (for example, you deleted a DataWriter) at the same time that Monitoring Library 2.0 (formerly called Observability Library) was gathering the periodic metrics of that resource. The thread may have accessed already freed memory.
When a resource was added (for example, you created a DataWriter), the thread could start gathering the periodic metrics of that resource before the resource was completely initialized. The thread may have accessed uninitialized memory.

Depending on the configured polling_period for periodic metrics and the frequency your application creates and deletes observable resources, the chances of the conditions explained above happening at the same time were unlikely.

These concurrency issues are now fixed. Monitoring Library 2.0 will not gather periodic metrics for resources that are being deleted or added.

[RTI Issue ID MONITOR-533]

4.16.3. Potential crash when configuring logging verbosity to NDDS_CONFIG_LOG_VERBOSITY_STATUS_LOCAL or higher

Connext Receive threads may have crashed as a result of a race condition during the Receive thread destruction process.

This problem, which was only possible when the Connext logging verbosity was set to NDDS_CONFIG_LOG_VERBOSITY_STATUS_LOCAL or higher (i.e., more verbose than STATUS_LOCAL), is now resolved: Receive threads no longer crash during their destruction.

[RTI Issue ID CORE-13649]

4.16.4. Malloc called when handling SIGSEGV

Previously, when handling a segmentation violation signal (SIGSEGV), it was possible for malloc to be called while logging backtrace information. In certain scenarios, this could cause another segmentation violation, and this cycle of events would continue indefinitely. Now, malloc will not be called when handling segmentation violation signals.

[RTI Issue ID CORE-13396]

4.16.5. Calling delete_contained_entities APIs could cause a crash in the thread that collects periodic metrics

If your application used any of the delete_contained_entities APIs (e.g., DDS_DomainParticipant_delete_contained_entities) and Monitoring Library 2.0 (previously called Observability Library) was still enabled, there was a possibility of a crash happening in the thread that collects periodic metrics. The crash happened because the children DDS Entities were removed before deleting their observable resources. Therefore, the periodic metrics thread could try to collect metrics for an observable resource whose DDS Entity no longer exists.

This issue is now fixed. The periodic metrics collector thread will not try to collect metrics for observable resources that are being deleted.

[RTI Issue ID MONITOR-549]

4.16.6. Application could crash when disabling and re-enabling Monitoring Library 2.0 due to internal error

If there was an error in an internal function of Monitoring Library 2.0 (formerly known as Observability Library), depending on the memory state an application using the Library could crash in the following scenario:

Monitoring Library 2.0 was enabled.
You created some DDS Entities (DomainParticipant, Publisher, DataReader …) in your application.
You disabled and re-enabled the Library. Due to an internal error, an exception was printed in the RTI_Monitoring_collectDdsResources function.
You deleted any DDS Entity before disabling the Library.

Because of the error in RTI_Monitoring_collectDdsResources, the observable resources associated with the DDS Entities were not updated for the second activation of the Library. The DDS Entities kept the old observable resources object from the previous activation, which were no longer valid.

When deleting the DDS Entities, these old observable resources were used without checking their validity. The behavior was undefined at that point and, depending on the memory state, the application could crash.

This issue is now fixed. Monitoring Library 2.0 no longer uses observable resources without checking their validity first.

[RTI Issue ID MONITOR-548]

4.16.7. Low-memory conditions could lead to crash on several platforms if allocation of high resolution clock failed

If the system was running very low in memory, a failure to allocate the high-resolution clock could then lead to a crash, since a NULL pointer would have been dereferenced while attempting to handle the failure. This issue applied to all platforms except Windows, Solaris, and Integrity, where the issue would not have occurred. This problem has been fixed.

[RTI Issue ID CORE-13899]