5.6.20. Memory Leaks/Growth

5.6.20.1. [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.6.20.2. [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.6.20.3. [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.6.20.4. [Major] Memory leak when parsing malformed XML defined types

A memory leak could be seen when trying to parse a malformed XML file filled with types.

[RTI Issue ID CORE-14662]

5.6.20.5. [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]

5.6.20.6. [Minor] Memory leak when parsing XML QoS profile with unknown base_name

When attempting to load an XML QoS profile, a memory leak occurred if the value of base_name was a non-existent QoS profile. For example, consider this invalid XML QoS profile:

<qos_library name="MyLibrary">
  <qos_profile name="MyProfile" base_name="BuiltinQosLib::Gengric.StrictReliable">
  </qos_profile>
</qos_library>

When attempting to load this XML file, you would correctly get the following error because of the typo in Gengric:

RTIXMLObject_initialize:Base object 'BuiltinQosLib::Gengric.StrictReliable' not found

However, you would also incorrectly get a memory leak in the internal function RTIXMLObject_initialize.

[RTI Issue ID CORE-14918]

5.6.20.7. [Minor] Memory leak during DomainParticipant creation when running out of memory trying to create the event thread

If the internal function RTIEventActiveGenerator_new ran out of memory, then DomainParticipant creation would fail with a memory leak. Here is one example error message, along with a valgrind result:

COMMENDActiveFacade_new:!create eventGenerator

==26292== 856 (480 direct, 376 indirect) bytes in 1 blocks are definitely lost in loss record 6 of 6
==26292==    at 0x4C33B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26292==    by 0x12EACB0: RTIOsapiHeap_reallocateMemoryInternal (heap.c:831)
==26292==    by 0x1BEF10D: RTIEventActiveGenerator_new (ActiveGenerator.c:712)

The leak would only happen if memory was already exhausted, so this problem did not lead to unbounded memory growth.

[RTI Issue ID CORE-14878]