6.4.13. Fixes Related to Crashes
6.4.13.1. [Critical] Rare segmentation fault when deleting DomainParticipant or Publisher containing DataWriters using durable writer history
A Connext application may have crashed after deleting a DomainParticipant or Publisher containing DataWriters using durable writer history. This issue has been fixed.
[RTI Issue ID CORE-12297]
6.4.13.2. [Critical] Segmentation fault when creation of DomainParticipant failed due to lack of resources
An application may have produced a segmentation fault using the release libraries if the creation of a DomainParticipant failed because the following resource limit was exceeded: participant_factory_qos.resource_limits.max_objects_per_thread.
With debug libraries, you may have seen a precondition error such as this:
FATAL U000000011d1a15c0_ [CREATE DP|LC:DISC]Mx06:/connextdds/event.1.0/srcC/activeDatabase/ActiveDatabase.c:275:RTI0x2000027:!precondition
This problem has been fixed.
[RTI Issue ID CORE-12654]
6.4.13.3. [Critical] Potential hang upon SIGSEGV signal from a Connext application
For debuggability purposes, Connext applications log a backtrace when a SIGSEGV signal is triggered.
In previous releases, this feature may have triggered a hang during the logging of the backtrace. In this release, we address this issue by disabling the logging of the backtrace by default in release libraries (but still keeping it enabled for debug libraries).
This default behavior can be modified by setting the new DomainParticipant-level property dds.participant.enable_backtrace_upon_sigsegv. See “New property to manually enable or disable logging backtrace upon SIGSEGV signal from a Connext application” in RTI Connext Core Libraries What’s New.
[RTI Issue ID CORE-12794]
6.4.13.4. [Critical] Creating DynamicDataTypePlugin with TypeCode from discovery and using content filtering caused segmentation fault
If the TypeCode that was received from endpoint discovery data (PublicationBuiltinTopicData.type_code or SubscriptionBuiltinTopicData.type_code) was used to create a DynamicDataTypeSupport in an application that was also using ContentFilteredTopics and setting ResourceLimitsQosPolicy.type_code_max_serialized_length to a non-zero value, the application issued a segmentation fault.
ResourceLimitsQosPolicy.type_code_max_serialized_length is 0 by default, which avoids the segmentation fault.
This issue has been fixed.
[RTI Issue ID CORE-12992]
6.4.13.5. [Critical] Application crash when calling DDS_DataReader_take_discovery_snapshot on a DataReader with a ContentFilteredTopic *
When taking a discovery snapshot by calling the DDS_DataReader_take_discovery_snapshot function on a DataReader with a ContentFilteredTopic, the application crashed when trying to obtain non-valid DomainParticipant information. This issue has been fixed. Now, DomainParticipant information is obtained correctly for DataReaders with ContentFilteredTopics.
[RTI Issue ID CORE-13011]
6.4.13.6. [Critical] Crash with NULL listeners and non-none status masks in C applications that mixed types with and without Zero Copy
In a C application, a crash occurred when both of these were true:
Types with and without Zero Copy transfer over shared memory were mixed inside the same DomainParticipantFactory instance.
A DataReader or DataWriter of the non-Zero Copy types had a NULL listener and a DDS_StatusMask different than DDS_STATUS_MASK_NONE.
The crash occurred because Connext invoked a NULL listener callback for the statuses enabled in the endpoints’ DDS_StatusMask.
When there is a Zero Copy type inside an application, some extra pre-processing related to Zero Copy is done before creating the endpoints and setting the listeners. In that extra pre-processing, for non-Zero Copy types, the NULL listener was incorrectly replaced with a non-null listener object with all its callbacks set to NULL. Then, Connext was not checking if the callbacks were NULL before calling them (the listener consistency is checked before the incorrect replacement; therefore, at that point, it was assumed the listener object was consistent).
This issue is fixed. The listener is no longer replaced with an invalid listener object, and Connext will always check if the callbacks are NULL before calling them.
[RTI Issue ID CORE-13151]
6.4.13.7. [Critical] Memory was read after it was freed by deleting a Topic with local logging level enabled
If the local logging level was enabled while deleting a topic, Connext would use recently freed memory from the deleted Topic to print a log message. Using the recently freed memory could cause a crash if local logging was enabled. A log message is now printed immediately before the Topic is deleted, so the possibility of using freed memory is eliminated.
[RTI Issue ID CORE-13226]
6.4.13.8. [Critical] Possible segmentation fault when disabling loopback interface
When a previously enabled loopback interface on a host computer was disabled, a segmentation fault could occur. The handling of loopback interfaces has been redesigned to remove this possibility.
[RTI Issue ID CORE-13228]
6.4.13.9. [Critical] Segmentation fault could occur if creation of DataReader failed
In some cases, a segmentation fault would occur if the creation of a DataReader failed. This problem has been fixed.
[RTI Issue ID CORE-13387]
6.4.13.10. [Critical] Potential crash when DomainParticipant deleted after creating DataWriter with automatic liveliness kind
There was a small possibility of a crash occurring when the DomainParticipant was deleted immediately after creating a DataWriter with an AUTOMATIC_LIVELINESS_QOS kind in the LIVELINESS QoS policy. This problem has been resolved.
[RTI Issue ID CORE-13524]
6.4.13.11. [Critical] Possible crash on TCP transport when large number of file descriptors were open
A Connext application that used the TCP transport and was built using _FORTIFY_SOURCE, which is set by default by some operating systems, could crash if one of the sockets for TCP had a file descriptor higher than FD_SETSIZE (1024). This issue has been fixed. Now, Connext overwrites the value of FD_SETSIZE, allowing an application using the TCP transport to open up to 32768 file descriptors, except on Android, where it is not possible to overwrite this value.
[RTI Issue ID COREPLG-644]
6.4.13.12. [Critical] Application using Monitoring Libraries may have produced segmentation fault during DataReader creation
In 6.0.x releases and above, an application using Monitoring Library may have produced a segmentation fault during DataReader creation. The issue was very rare and only occurred if a DataReader received a sample immediately after being enabled. This issue has been fixed.
[RTI Issue ID MONITOR-429]
6.4.13.13. [Critical] Possible segmentation fault when using Monitoring Library
When using monitoring libraries, a rare race condition may have led to a segmentation fault. This issue was more likely to occur if the Connext application using the monitoring libraries created and deleted entities often. This problem has been resolved.
Note: This problem was reported as fixed in MONITOR-252, in release 6.0.1; however, that fix did not apply to Publishers and Subscribers. This fix protects applications when frequently creating and deleting Publisher or Subscriber entities as well.
[RTI Issue ID MONITOR-516]
* This bug does not affect you if you are upgrading from 6.1.x or earlier.