6.4.14. Other Fixes

6.4.14.1. [Critical] Broken communication when DataWriter with transport priority discovered DataReader with multicast receive address

If a DataWriter that had a non-default DataWriterQos.transport_priority value set discovered a DataReader with a multicast receive address, the DataWriter and any other DataWriters within the same participant were not able to send any traffic over unicast. This could cause communication failures in a number of different scenarios, including a broken reliability protocol due to the inability to send heartbeats over unicast or the inability to communicate with other DataReaders that have not been configured to use a multicast receive address.

This issue was introduced in 6.1.0. This issue has been resolved.

[RTI Issue ID CORE-12772]

6.4.14.2. [Critical] Potential hang upon SIGSEGV signal from a Connext application

For debuggability purposes, Connext applications have the ability to flog 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 in release libraries (but still keeping it enabled for debug libraries).

This default behavior can be modified by setting a new participant-level property, dds.participant.enable_backtrace_upon_sigsegv. The accepted values for this new property are: “auto” for the default behavior (backtrace only enabled in debug libraries), “true” for enabling the logging of the backtrace, and “false” for disabling it.

Note: This property takes effect upon the creation of the first DomainParticipant within a process. Consequently, if a SIGSEGV signal is received before the creation of the first DomainParticipant, the default behavior will be applied (backtrace enabled in debug libraries and disabled in release libraries).

[RTI Issue ID CORE-12794]

6.4.14.3. [Critical] Samples could be lost using group order access or collaborative DataWriters

There was a possibility of DataReader queue corruption, when using group order access or collaborative DataWriters, that may have provoked the DataReader to stop receiving samples. The possibility was very small and may have occurred randomly since it was caused by an uninitialized flag.

[RTI Issue ID CORE-13153]

6.4.14.4. [Critical] Release 6.1.2 was not FACE compliant

The |CONNEXTDDS_ITALIC| 6.1.2 release was not FACE compliant due to usage of the realpath system call. This problem has been resolved.

[RTI Issue ID CORE-13340]

6.4.14.5. [Critical] Using dh_param_files leaked memory

Using the property tls.cipher.dh_param_files leaked memory when deleting the DomainParticipant. A memory checking tool, such as valgrind, would have reported the leak in the OpenSSL function PEM_read_bio_DHparams, which is called by the RTI function RTITLS_tmp_dhparam_callback. This problem only affected applications using OpenSSL 1.0.2 or applications communicating with applications using OpenSSL 1.0.2. For example, TLS Support 5.3 uses OpenSSL 1.0.2, but version 7.0.0 of TLS Support could still communicate with version 5.3, so the leak could also happen in version 7.0.0.

This problem has been fixed; memory will no longer be leaked in this scenario. For example, if TLS Support 7.1.0 communicates with an application using OpenSSL 1.0.2, the leak will not occur.

[RTI Issue ID COREPLG-641]

6.4.14.6. [Critical] Segmentation fault when mixing build types in applications linked against libraries in “Find Package” Cmake script

Mixing Release and Debug build types in applications linked against Connext libraries in the “Find Package” script (FindRTIConnextDDS.cmake) could lead to undesired behaviors like double-freeing pointers, once for the Debug symbol and once for the Release symbol, and in the end causing the application to abort.

The new CONNEXT_LIBS_BUILD_TYPE CMake variable has been added to control the Connext libraries build type (Release/Debug). This variable will allow three values: Auto, Release, and Debug.

By default (the Auto value), FindRTIConnextDDS.cmake will populate the IMPORTED_LOCATION_DEBUG and IMPORTED_LOCATION_RELEASE properties of all the Connext imported target libraries. This means that the Connext libraries will be provided in the same build type as the global build (specified by the CMAKE_BUILD_TYPE value).

If you provide Release or Debug values to the CONNEXT_LIBS_BUILD_TYPE variable, the script will force populating only the IMPORTED_LOCATION property of the Connext imported target libraries. So, regardless of the CMAKE_BUILD_TYPE value, the Connext libraries will have the build type given in the CONNEXT_LIBS_BUILD_TYPE variable.

[RTI Issue ID INSTALL-793]

6.4.14.7. [Major] Error sending batch when batch size exceeded transport MTU

A DataWriter configured to use batching may have failed to send a batch to the destination addresses associated with a transport (e.g, UDPv4) if the batch size exceeded the message_size_max (MTU) of the transport.

This problem has been resolved. Now, the batch is automatically flushed when exceeding the minimum message_size_max across all installed transports.

[RTI Issue ID CORE-2639]

6.4.14.8. [Major] No more than 100 asynchronous publisher threads could be created

A change to the thread naming convention inadvertently limited the number of asynchronous publisher threads to 100. The limit is now 65,536. These limits also apply to receive threads, asynchronous waitset threads, and persistence service threads.

[RTI Issue ID CORE-12874]

6.4.14.9. [Major] Unexpected precondition error while creating a DomainParticipant with debugging libraries using fast database cleanup period

You may have seen the following precondition error while creating a DomainParticipant with debugging libraries if participant_qos.database.cleanup_period was updated to a small value.

FATAL rCo96144####Dtb Mx0D:/rti/jenkins/workspace/connextdds_ci_fastbuild-debug_develop/pres.1.0/srcC/participant/Participant.c:3102:RTI0x200003b:!precondition: "me->_service == ((void *)0)"

Release libraries did not have this issue.

This problem has been fixed.

[RTI Issue ID CORE-13204]

6.4.14.10. [Major] In FindPackage script, low_bandwidth_edisc imported target library was missing

In the “FindPackage” script (FindRTIConnextDDS.cmake), the low_bandwidth_edisc imported target library was missing, incorrectly named low_bandwidth_discovery_static. When you tried to link against low_bandwidth_discovery_static, the script actually linked against the LOW_BANDWIDTH_EDISC libraries. And you couldn’t link against low_bandwidth_edisc because there was no imported target with that name.

In the following example, the second TARGET should have been called low_bandwidth_edisc:

######################## Low bandwidth plugins #########################
    # Discovery Static
    create_connext_imported_target(
        TARGET "low_bandwidth_discovery_static"
        VAR "LOW_BANDWIDTH_DISCOVERY_STATIC"
        DEPENDENCIES
            RTIConnextDDS::c_api
    )

    # EDISC
    create_connext_imported_target(
        TARGET "low_bandwidth_discovery_static"
        VAR "LOW_BANDWIDTH_EDISC"
        DEPENDENCIES
            RTIConnextDDS::c_api
    )

This problem has been fixed.

[RTI Issue ID INSTALL-719]

6.4.14.11. [Minor] Potential memory leak when creation of any of the built-in discovery plugins failed

The first time a DomainParticipant is created in an application, some memory is allocated globally for each of the builtin discovery plugins (SPDP and SEDP) enabled for that DomainParticipant. This global memory is released when finalizing the DomainParticipantFactory instance.

However, if there was a failure in the creation of any of the builtin discovery plugins during the DomainParticipant creation, the DomainParticipantFactory was not notified properly that this global memory was allocated. Therefore, finalizing the DomainParticipantFactory instance did not release the memory, causing a leak.

This problem is fixed. Finalizing the DomainParticipantFactory instance always releases the memory if it was previously allocated, regardless of whether or not a failure occurred.

[RTI Issue ID CORE-12882]

6.4.14.12. [Minor] Problems visualizing participants using Generic.MinimalMemoryFootprint profile with Admin Console

RTI Admin Console could not correctly visualize DomainParticipants using the Generic.MinimalMemoryFootprint profile. Some of the information, such as process ID and host name, was invalid. This problem has been fixed.

[RTI Issue ID CORE-13509]

6.4.14.13. [Minor] Failure to load a string-based private key leaked memory

If you set the property tls.identity.private_key or tls.identity.rsa_private_key, and you either specified a wrong or missing value for the property tls.identity.private_key_password or specified a malformed private key, then memory would be leaked upon DomainParticipant creation failure. A memory checking tool, such as valgrind, would report the leak in the OpenSSL function BIO_new_mem_buf, which is called by the RTI function RTITLS_context_init.

This problem has been fixed. Memory will no longer be leaked in this scenario.

[RTI Issue ID COREPLG-643]

6.4.14.14. [Minor] CONNEXTDDS_ARCH environment variable in FindPackage script was not picked up correctly

Previously, only the CONNEXTDDS_ARCH CMake variable in the “FindPackage” script (FindRTIConnextDDS.cmake) could be used to define the Connext official architecture to use. Now, the environment variable with the same name can be used, too.

[RTI Issue ID INSTALL-691]

6.4.14.15. [Trivial] Incorrect “Supported platforms” documentation section for FindRTIConnextDDS.cmake

Now the documentation section in the “FindPackage” script (FindRTIConnextDDS.cmake) file listing the “Supported platforms” matches the Core Libraries Platform Notes.

[RTI Issue ID INSTALL-548]