5.23. Memory Leaks/Growth

5.23.1. [Critical] Spike in memory usage when creating a DataWriter using Durable Writer History to restore samples

When creating a DataWriter that used Durable Writer History to restore a large number of samples, the memory usage incorrectly grew to a large amount and then shrunk back down. This problem has been fixed by reducing the memory usage.

[RTI Issue ID CORE-15802]

5.23.2. [Critical] Memory leaks and errors when using DynamicDataReaders or FlatData DataReaders plus DDS-fragmentation and compression or encryption *

When a DynamicDataReader or DataReader using a FlatData type received a fragmented sample that was either compressed or encrypted, the memory used to store the sample’s serialized data was leaked and errors similar to the following would have been printed:

FATAL rCo79661##01Rcv [PARSE MESSAGE|0x01016350,0x5A66C0E7,0x8DA940ED:0x80000004{Entity=DR,MessageKind=DATA_FRAG}|RECEIVE FROM 0x01018673,0xDB0C9361,0xB2B4181F:0x80000003] Mx02:/home/user/osapi.1.0/srcC/memory/heap.c:1104:RTI0x2022004:inconsistent free/alloc: block id 0 being freed with "RTIOsapiHeap_allocateBufferAligned" and was allocated with "RTIOsapiHeap_unknownFunction"

[RTI Issue ID CORE-15231]

5.23.3. [Critical] Possible unbounded memory growth on DataReader of keyed type after failing to match with a remote DataWriter

Consider the following scenario:

• You have a DataReader of a keyed type.

• The DataReader discovers a DataWriter, but the matching process fails somehow (e.g., due to a port collision that generates this error: assertRemoteWriter:!create entryPort).

• The DataReader somehow retries the matching process with the same DataWriter (e.g., due to receiving another discovery announcement for the DataWriter after the DataWriter changes its QoS).

The matching process would fail again and generate this error: PRESCstReaderCollator_getRemoteWriterQueue:FAILED TO ASSERT | remote writer queue node in list. Repeated occurrences of this error message were correlated with an unbounded memory growth on the DataReader.

This problem only affected Connext version 7.4.0, versions 7.1.0 to 7.3.0.2, versions 6.1.2.4 to 6.1.2.20, versions 6.0.1.33 to 6.0.1.38, and versions 5.3.1.43 to 5.3.1.44.

[RTI Issue ID CORE-15095]

5.23.4. [Critical] Unbounded memory growth when using RECOVER instance state consistency and instances were removed from DataReader queue *

If you set ReliabilityQosPolicy::instance_state_consistency_kind=RECOVER, each time an instance was removed from the DataReader queue some internal state about the remote writers of that instance was leaked.

Instances can be removed from the queue for the following reasons:

• An instance was disposed and ReaderDataLifecycle::autopurge_disposed_instances_delay was set to a finite value,

• Or you set a finite ResourceLimits::max_instances value and configured DataReaderResourceLimits::instance_replacement to allow instance replacement when that limit was hit.

Note: If an instance was removed because there were no more writers for that instance, there was no leak because there was no remote writer information to leak about that instance.

[RTI Issue ID CORE-15091]

5.23.5. [Critical] Parsing DTD with many nested/recursive entities could cause uncontrolled resource consumption

A Document Type Definition (DTD) with several nested or recursive entities could have caused uncontrolled resource consumption. This could have occurred when the DTD was parsed by expat (third-party software used by Connext). This problem has been addressed by upgrading expat to version 2.6.2.

[RTI Issue ID CORE-14576]

5.23.6. [Critical] Parsing XML configuration with large tokens caused uncontrolled resource consumption

If you added a very large token (greater than 1 MB) to an XML file parsed by Connext, it could have caused uncontrolled resource consumption since the underlying XML parser would frequently reallocate memory to store the token. This problem has been addressed by upgrading expat to version 2.6.2.

[RTI Issue ID CORE-14529]

5.23.7. [Critical] Unbounded memory growth when using DynamicDataReaders with multiple data representations and keyed types

There was an unbounded memory growth when a DynamicDataReader was using a keyed type and had the DataRepresentationQosPolicy set to XCDR | XCDR2. In order to run into the growth, the key of the data type had to contain a string or a sequence. The growth happened every time a sample was received from a DataWriter that was publishing data using XCDR DataRepresentation because the DynamicDataReader had to calculate the XCDR2 version of the keyhash. The memory used to calculate that keyhash was never released, leading to the unbounded growth.

[RTI Issue ID CORE-14437]

5.23.8. [Critical] Potential unbounded memory growth when using DNS tracking

Connext allows adding peers based on a hostname instead of an IP address. When the dns_tracker_polling_period is set, Connext attempts to update the address resolution of these hostnames at this period.

It was possible to experience an unbounded memory growth when using initial_peers that had overlapping sets of hostnames and IP addresses. For example, consider a DomainParticipant that was using the following initial_peers: {[1]@udpv4://hostname, [4]@udpv4://hostname, [2]@udpv4://127.0.0.1, [3]@udpv4://127.0.0.1, [4]@udpv4://127.0.0.1}. If hostname resolved to 127.0.0.1, the DomainParticipant would duplicate the entry for [4]@udpv4://127.0.0.1 when updating the DNS resolution. This would also result in duplicate discovery traffic sent to that locator. Now the memory leak and duplicate discovery traffic no longer occur.

[RTI Issue ID CORE-14151]

5.23.9. [Major] RTI DDS Spy showed DDS_DataReader_get_matched_publication_participant_data error before leaking memory *

When discovering the deletion of a DataWriter or DataReader immediately after discovering the deletion of the DomainParticipant associated with the DataWriter or DataReader, DDS Spy incorrectly generated these errors before leaking memory:

DDS_DataReader_get_matched_publication_participant_data:ERROR: Failed to get discovered_participant_data
get_matched_publication_participant_data error 4
ERROR DDS_SampleInfoSeq_set_maximum:failed to assert buffer must not be loaned

This problem only affected versions 7.3.0 and above.

[RTI Issue ID CORE-15629]

5.23.10. [Major] DomainParticipantFactory finalization failed even if all the DomainParticipants were deleted

When creating or deleting DomainParticipants concurrently from different threads, the finalization of the DomainParticipantFactory could fail, stating that “Not all the participants created were destroyed” even after deleting all the DomainParticipants.

[RTI Issue ID CORE-14609]

5.23.11. [Minor] Memory leak upon Transport TCP creation failure because of invalid configuration

A failure during Transport TCP creation may have triggered a memory leak. The leak triggered when providing an invalid PropertyQos configuration to the transport.

[RTI Issue ID COREPLG-755]

5.23.12. [Minor] Possible memory leak when initializing and finalizing the DomainParticipantFactory concurrently

If one thread was initializing the DomainParticipantFactory (e.g., by calling DDSDomainParticipantFactory::get_instance() in traditional C++) and another thread was finalizing the DomainParticipantFactory (e.g., by calling DDSDomainParticipantFactory::finalize_instance() in traditional C++) at the same time, then a memory leak in the internal functions RTIOsapiContext_associateThread and RTIOsapiContextSupport_assertContextTss was possible due to a race condition. This problem did not lead to unbounded memory growth and only affected releases 6.1.0 to 7.4.0.

[RTI Issue ID CORE-14972]

* This bug did not affect you if you are upgrading from 6.1.x or earlier.