5.4.19. Memory Leaks/Growth

5.4.19.1. [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.4.19.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.4.19.3. [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.4.19.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.4.19.5. [Major] Memory leak when parsing invalid module in XML

A memory leak could be seen when trying to parse an invalid module in XML. For example:

<module name="MyModule1" autoid='hash' transferMode='invalid value'>

[RTI Issue ID CORE-15406]

5.4.19.6. [Major] Memory leak when using DynamicData with types containing optional members of string aliases or when cloning such types

Consider the following type definition:

typedef string EntityName;
struct Entity {
    @key uint64_t id;
    @optional EntityName name;
};

The following C code would have resulted in a 1-byte memory leak in previous releases:

dynData = DDS_DynamicData_new(
    Entity_get_typecode(),
    &DDS_DYNAMIC_DATA_PROPERTY_DEFAULT);
DDS_DynamicData_delete(dynData);

The problem occurred when the DynamicData object was associated with a type containing optional members of string aliases. The problem affected all languages.

The same problem also occurred when cloning a TypeCode for a type containing optional members of string aliases. For example, the following C code would have leaked 1 byte:

cloneTc = DDS_TypeCodeFactory_clone_tc(
        DDS_TypeCodeFactory_get_instance(),
        Entity_get_typecode(),
        &ex);
DDS_TypeCodeFactory_delete_tc(
        DDS_TypeCodeFactory_get_instance(),
        cloneTc,
        &ex);

[RTI Issue ID CORE-15539]

5.4.19.7. [Minor] DynamicDataTypeSupport objects not reclaimed by garbage collector

When a DynamicDataTypeSupport was registered with a DomainParticipant, the DynamicDataTypeSupport object was forever unreclaimable. This was the result of a leaked Java Native Interface (JNI) global reference.

[RTI Issue ID CORE-14359]

5.4.19.8. [Minor] Potential DynamicData sample leaked on DataReader deletion

When using DynamicData DataReaders, an internally-created sample might have been leaked if the DynamicDataTypeSupport was deleted before the DataReader.

[RTI Issue ID CORE-14324]