4.19. Memory Leaks/Growth

4.19.1. [Critical] Memory use by Monitoring Library 2.0 may have grown unbounded over time

The memory used by Monitoring Library 2.0 could grow without bound over time. This behavior was more noticeable in highly dynamic systems where entities are frequently created and destroyed, or where liveliness conditions change continuously.

[RTI Issue ID MONITOR-751]

4.19.2. [Critical] Unbounded memory growth when setting receive_window_size on DataReader

There was a potential for unbounded memory growth under the following conditions:

The application created at least one reliable DataReader with reader_qos.protocol.rtps_reliable_reader.receive_window_size set to a value larger than the default (256).
DataReader instances with this configuration were created and deleted continuously.

Under these circumstances, memory usage could grow without bound. This issue was rare, and the memory increase occurred very slowly.

[RTI Issue ID CORE-16532]

4.19.3. [Critical] Memory leak in DataWriter when matching reliable DataReader

In Connext 6.1.0 a memory growth in a DataWriter when matching a reliable DataReader, which had been fixed via CORE-7652, was reintroduced. As a result, a DataWriter kept a small amount of memory around for a matching DataReader, even if the DataReader was deleted and unmatched. This may have led to unbounded memory growth over time as new DataReaders were created and destroyed. Notice that the leaked memory was returned to the heap after the DataWriter was deleted. Now the memory is managed properly and returned after the DataReader is unmatched.

[RTI Issue ID CORE-16299]

4.19.4. [Critical] History depth not honored after instance transitioned from NOT_ALIVE to ALIVE state

If an instance transitioned from a NOT_ALIVE state to the ALIVE state while there was a loan on the NOT_ALIVE sample, a mismatch occurred in the internal DataReader counters, making the DataReader not honor the History depth for that instance. If the History depth was set to 1 after the issue happened, there would be 2 samples allowed for that instance. Now the History depth is properly honored in this case.

[RTI Issue ID CORE-16369]

4.19.5. [Major] Memory leak when UDP receive socket creation failed

This issue was fixed in release 7.5.0, but not documented at that time.

If Connext failed to create a UDP socket for receiving messages on a specific port or multicast address, not all allocated memory was properly released, resulting in a memory leak.

Before the memory leak occurred, errors were logged in the NDDS_Transport_UDP_create_recvresource_rrEA function.

This issue affected any UDP transport plugin: UDPv4, UDPv6, or RTI Real-Time WAN Transport.

[RTI Issue ID CORE-16415]

4.19.6. [Major] Memory leak in Monitoring Library 2.0 when mixing library types

A memory leak occurred when enabling Monitoring Library 2.0 in applications mixing different library types; for example, when linking statically to Connext libraries while attempting to dynamically load the Monitoring Library 2.0. In such scenarios, Monitoring Library 2.0 activation would fail and leak the library’s internal representation.

[RTI Issue ID MONITOR-754]

4.19.7. [Minor] Unbounded memory growth in Modern C++ when creating and deleting DynamicData topics of the same type

In Modern C++, there was an unbounded memory growth (which manifested as a struct DDS_DynamicDataTypeSupport in a heap snapshot) when creating and deleting DynamicData topics of the same type. For example, if you did the following:

DomainParticipant participant(domain_id());
StructType type("sometype");
type.add_member(Member("a", PrimitiveType<int32_t>()));
for (int i = 0; i < 10000; ++i) {
    dds::topic::Topic<DynamicData> topic(participant, "AppTopic", type);
}
rti::util::heap_monitoring::take_snapshot("myHeapSnapshot.txt");

you would incorrectly see 10000 DDS_DynamicDataTypeSupport structures in myHeapSnapshot.txt. The correct behavior is to see only one DDS_DynamicDataTypeSupport structure in the heap snapshot. This problem has been fixed in the Modern C++ API and may still exist in other language APIs.

[RTI Issue ID CORE-16007]

4.19.8. [Minor] Memory leak when disabling Monitoring Library 2.0 in Traditional C++

If Monitoring Library 2.0 was enabled in a Traditional C++ application, you would have experienced a memory leak in the C function DDS_DomainParticipantFactory_get_instance. This leak only occurred when disabling Monitoring Library 2.0 and did not lead to unbounded memory growth while Monitoring Library 2.0 was enabled.

[RTI Issue ID MONITOR-757]