5.1. Regressions in 6.1.0¶

5.1.1. Core Libraries¶

5.1.1.1. XSD Issue: order enforced in <publisher> tag¶

This regression was introduced in 6.0.0 and has not been fixed. See XSD issue: order enforced in <publisher> tag in the 6.0.0 Regressions section.

5.1.1.2. Memory leak modifying flow_controller_name or filter_name QoS programmatically with DDS_String_dup¶

This regression was introduced in 6.0.0 and has not been fixed. See Memory leak modifying flow_controller_name or filter_name QoS programmatically with DDS_String_dup in the 6.0.0 Regressions section.

5.1.1.3. Samples lost if multiple readers were created in same locator and push_on_write was set to false¶

This regression was introduced in 6.0.1 and has not been fixed. See Samples lost if multiple readers were created in same locator and push_on_write was set to false in the 6.0.1 Regressions section.

5.1.1.4. XML parser crashed from infinite recursion when XML QoS configuration contained inheritance loop¶

This regression was introduced in 6.0.1 and has not been fixed. See XML parser crashed from infinite recursion when XML QoS configuration contained inheritance loop in the 6.0.1 Regressions section.

5.1.1.5. Invalid serialization of samples with types containing nested structures with primitive members that require padding¶

In releases 6.0.1.20 and 6.1.0, the serialization of samples with a type containing one or more levels of nested complex types, where the nested types only have primitive members, may fail. This means that a DataReader may receive an invalid value for a sample. For example:

struct MyType2 {
    long m21;
    long m22;
    double m23;
};

struct MyType {
    long m1;
    MyType2 m2;
};

This issue only applies when all of these conditions apply:

The user uses XCDR (Extensible CDR version 1) data representation.
The top-level type (MyType above) and the nested type containing only primitive members (MyType2 above) are appendable or final.
There is a padding in the equivalent C/C++ type between the nested type member (m2 above) and the previous member (m1 above). In the above example, there is a 4-byte padding between m1 and m2 in MyType.

This problem affects DynamicData and the generated code for the following languages: C, C++, C++03, C++11, and the new C# binding.

For generated code, a potential workaround to this problem is to generate code with a value of 1 or 0 for the -optimization parameter, but this may have performance implications.

This problem will be fixed in an upcoming patch or release.

[RTI Issue ID CORE-11604]

5.1.1.6. Significant performance degradation when using MultiChannel DataWriters¶

In release 6.1.0, you may observe a significant performance degradation compared to previous releases when using MultiChannel DataWriters.

Release 6.1.0 introduced a regression in which a DataReader ends up subscribing to all the multicast addresses associated with a DataWriter’s channels instead of subscribing to only the multicast addresses that can provide samples that pass the DataReader ContentFilteredTopic.

Note that this issue does not affect correctness, because the DataReader ends up filtering locally the samples that did not pass its ContentFilteredTopic expression.

This problem has been resolved.

If your application uses MultiChannel DataWriters, please contact support@rti.com to get a patch.

[RTI Issue ID CORE-11742]

5.1.2. RTI Code Generator¶

5.1.2.1. Change in behavior in C and traditional C++ for bounded sequences under certain conditions¶

This regression was introduced in 6.0.0 and has not been fixed. See Change in behavior in C and traditional C++ for sequences of bounded strings under certain conditions when code is generated with optimization level 1 or 2 in the 6.0.0 Regressions section.

5.1.2.2. Invalid serialization of samples with types containing nested structures with primitive members that require padding¶

See Invalid serialization of samples with types containing nested structures with primitive members that require padding above.

5.1.3. RTI TLS Support¶

5.1.3.1. hello_world_tcp example root and intermediate CAs expire too early¶

In rti_workspace/examples/connext_dds/c/hello_world_tcp, the README.txt states:

Example certificates for two peers are included in dds_security/cert/tls_rsa01.

But the root CA certificate ca/rsa01RootCaCert.pem, which is the intended command-line argument for --tls-cert, expires only 30 days after it is created. The root CA certificate is therefore unusable and leads to communication failure along with the following errors:

RTITLS_ConnectionEndpointTLSv4_doHandshake:OpenSSL protocol error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
RTITLS_ConnectionEndpointTLSv4_doHandshake:OpenSSL protocol error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired

In the identities folder, the files rsa01Peer01.pem and rsa01Peer02.pem have intermediate CAs in them, and those intermediate CAs also expire.

These problems only affect release 6.1.0 and will be fixed in an upcoming release.

As a workaround, you may use the certificates from dds_security/cert/dtls_rsa01 instead of dds_security/cert/tls_rsa01.

[RTI Issue ID COREPLG-554]

5.1.4. RTI Security Plugins¶

5.1.4.1. Performance regression on Windows when using OpenSSL 1.1.1 libraries in 6.1.0¶

Previously, OpenSSL was built using compiler flags that enabled the usage of assembly instructions for certain operations on certain operating systems like Windows 64-bit (but not 32-bit).

The OpenSSL 1.1.1k Windows libraries provided with Connext DDS 6.1.0 were missing those compiler flags. As a result, the performance of Security Plugins, TLS Support, and DTLS transport, which rely on those libraries, has been degraded.

As a workaround, the OpenSSL 1.1.1k libraries provided with Connext DDS 6.0.1.22 can be used instead.

[RTI Issue ID SEC-1458]

5.1.4.2. Permissions document incorrectly disallowed unescaped special characters in a subject name¶

In releases 6.0.1.22 and 6.1.0, if a <subject_name> in the signed Permissions Document contains special characters that are not escaped with quotes, then DomainParticipant creation will incorrectly fail. For example, if the subject name has slashes:

<subject_name>CN=/common/name</subject_name>

then DomainParticipant creation will fail with the following errors:

RTI_Security_XMLPermissionsGrantHelper_subjectNameToX509name:!common attribute value must be preceded by '='
RTI_Security_XMLPermissionsGrant_onEndTag:Parse error at line 4: invalid subject_name. Format: name1=value1, name2=value2, etc.
RTIXMLParser_parseFromString_ex:error parsing XML string
RTI_Security_PermissionsCfgFileParser_parse:!error parsing XML file

The affected special characters are \/;=

This problem will be fixed in an upcoming patch or release. The only character that should need to be escaped with quotes is , because commas are the standard attribute separator according to RFC 4514. For example,

<subject_name>CN="a, TwitterHandle=@guy"</subject_name>

is valid because of the quotes. Without the quotes, DomainParticipant creation would fail due to the unknown attribute name “TwitterHandle”. Note that the quotes would be included in the output of

openssl x509 -in <identityCertificateFile> -text -noout

which is the command that you should use to get the subject name that should go in the Permissions Document.

Updating Permissions Files with New Credentials, in the RTI Security Plugins Getting Started Guide, mentions using the openssl x509 command to extract a correctly-formatted subject name from a certificate. While this method is always correct and hassle-free, an alternative would be to simply copy-paste the subject name from the certificate file itself. Unfortunately, this alternative may not be reliable, depending on the openssl command used to generate the certificate. If the certificate file was generated using openssl ca, then the subject name from the certificate file itself would not be formatted correctly. If the certificate file was generated using openssl x509 -req, then the subject name from the certificate file would have the correct format. As an example of changing the openssl command, if we follow Generating Identity Certificates, in the RTI Security Plugins Getting Started Guide,

openssl ca -config ca/pmiIdentityCa.cnf -days 730 -in identities/pmiAlice.csr -out identities/pmiAliceCert.pem

would be changed to

openssl x509 -req -days 730 -text -CAserial ca/database/pmiIdentityCaSerial -CA ca/pmiIdentityCaCert.pem -CAkey ca/private/pmiIdentityCaKey.pem -in identities/pmiAlice.csr -out identities/pmiAliceCert.pem

[RTI Issue ID SEC-1428]

5.1.5. RTI Routing Service¶

5.1.5.1. Crash in Routing Service executable when providing the same -Dname=value pair twice¶

When launching Routing Service and using the -Dvar=value command-line option to provide values for XML configuration variables, repeating the same variable twice in the command can result in a crash.

For example, this command includes -DPUBLIC_ADDRESS=10.10.10.1 twice:

>c:\Rti\rti_connext_dds-6.1.0\bin\rtiroutingservice.bat -cfgFile rti_rs_example_tcp_wan.xml -cfgName WanGateway -appName GatewaySiteA -DPUBLIC_ADDRESS=10.10.10.1 -DBIND_PORT=10 -DREMOTE_RS_PEER=1 -DLAN_DOMAIN_ID=2 -DPUBLIC_ADDRESS=10.10.10.1

This results in the following crash:

Backtrace:
#4 RTIOsapiThread_newWithStack [0x5C8D5DE0]
#5 UnhandledExceptionFilter [0xA216C060]
#6 [0xA1C3A448]
#7 [0xA1C3A290]
#8 memset [0xA49D3EC0]
#9 _C_specific_handler [0xA49BC6E0]
#10 _chkstk [0xA49D2060]
#11 RtlRaiseException [0xA4981020]
#12 KiUserExceptionDispatcher [0xA49D0C80]
#13 strstr [0x8CD26AEC]
#14 RTI_RoutingServiceProperties_lookup_property_with_prefix [0x5CDB1CF0]
#15 RTI_Service_Monitoring_ResourceGuid_finalize_w_return [0x5CE24550]
#16 RTI_Service_Monitoring_ResourceGuid_finalize_w_return [0x5CE24550]
#17 RTI_Service_Monitoring_ResourceGuid_finalize_w_return [0x5CE24550]
#18 RTI_Service_Monitoring_ResourceGuid_finalize_w_return [0x5CE24550]
#19 RTI_Service_Monitoring_ResourceGuid_finalize_w_return [0x5CE24550]
#20 ROUTERService_isStarted [0x5CEA2B60]
#21 ROUTERService_finalizeGlobals [0x5CEA2060]
#22 ROUTERService_new [0x5CEA3860]
#23 RTI_RoutingService_new_from_description [0x5CEAE200]
#24 RTI_RoutingService_new [0x5CEAE150]
#25 [0xAD2E196E]
#26 RTI_RoutingServiceVersion_compare [0xAD2E3050]
#27 BaseThreadInitThunk [0xA4187020]
#28 RtlUserThreadStart [0xA4982630]
U0000000000004688 [/routing_services/WanGateway|CREATE] Mx02:C:\<path>\connextdds\6.1.0.0\x64Win64VS2012\src\osapi.1.0\srcC\thread\Thread.c:3647:RTI0x2000005:Received EXCEPTION_ACCESS_VIOLATION

The solution is to review the list of variables thoroughly and make sure the same name/value pair is not provided more than once.

This problem will be fixed in an upcoming patch or release.

[RTI Issue ID ROUTING-881]