5.1.9. Fixes Related to XML Configuration
5.1.9.1. Memory leak after an error parsing XML file with <include> tag
If the user’s application failed to parse an XML file containing an <include> tag, this caused a memory leak. For example:
<types>
<include file=""myFile.xml"">
<struct name=""MyStruct"">
<member name=""m1"" type=""unknownType"" />
</struct>
</types>
This file cannot be parsed because m1 refers to an unknown type. When the application finished, running a memory profiling tool such as ValgrindTM showed there was a memory leak. This problem has been resolved.
[RTI Issue ID CORE-12831]
5.1.9.2. Failed to parse XML configuration file containing type member with useVector attribute
Connext libraries failed to parse XML files containing a type member with the attribute useVector, although this is a legal attribute.
For example:
<types>
<struct name= "MyType">
<member name="m1" sequenceMaxLength="100" useVector="true" type="int32"/>
</struct>
</types>
Parsing this file failed with the following error:
RTIXMLParser_validateOnStartTag:Parse error at line xxx: Unexpected attribute 'useVector'
This problem has been fixed.
[RTI Issue ID CORE-12949]
5.1.9.3. XML composition overwrote system information properties with defaults instead of correct values
The XML composition mechanism (described in QoS Profile Inheritance and Composition) had an issue with the way system properties (described in System Properties) set in an XML Snippet were applied to a <domain_participant_qos> in an XML Profile referencing the Snippet. The properties set in the XML Snippet were not applied to the <domain_participant_qos>, which ended up using the automatic values generated by Connext.
Here is an example that illustrates the problem:
<qos_library name="SampleQoSLib">
<qos_profile name="ParentProfile">
<domain_participant_qos>
<property>
<value>
<element>
<name>dds.sys_info.hostname</name>
<value>CustomHostName</value>
</element>
</value>
</property>
</domain_participant_qos>
</qos_profile>
<qos_profile name="ChildProfile" is_default_qos="true">
<domain_participant_qos>
<base_name>
<element>SampleQosLib::ParentProfile</element>
</base_name>
<property>
<value>
<element>
<name>dds.sys_info.username</name>
<value>CustomUserName</value>
</element>
</value>
</property>
</domain_participant_qos>
</qos_profile>
</qos_library>
The <domain_participant_qos> in the ChildProfile ended up with the following values for the system information properties:
dds.sys_info.hostname - The default value rather than the CustomHostName value as set in the <domain_participant_qos> in ParentProfile, because of the overwriting problem described above.
dds.sys_info.username - The set value of CustomUserName, which is the correct value.
This issue has been resolved.
[RTI Issue ID CORE-13090]