8.7. Regressions in 6.1.0
The following regressions occur in Connext 6.1.0.
8.7.1. Core Libraries
8.7.1.1. Fixed in 7.4.0
8.7.1.1.1. 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.
[RTI Issue ID CORE-14972]
8.7.1.2. Fixed in 7.1.0 and 6.1.2
8.7.1.2.1. DomainParticipant with non-default metatraffic_transport_priority QoS does not complete discovery
A DomainParticipant that has a non-default metatraffic_transport_priority
in the
DISCOVERY QoS Policy cannot complete endpoint discovery due to a unicast
metatraffic channel that is not created correctly. (The channel is used by the
participant to send Data(R) and Data(W).) This issue is introduced in 6.1.0 and
fixed in releases 6.1.2 and 7.1.0.
[RTI Issue ID CORE-12739]
8.7.1.2.2. Broken communication when DataWriter with transport priority discovers DataReader with multicast receive address
If a DataWriter that had a non-default DataWriterQos.transport_priority
value set
discovered a DataReader with a multicast receive address, the DataWriter, and any other
DataWriter within the same participant, was not able to send any traffic over unicast.
This could cause communication failures in a number of different scenarios,
including a broken reliability protocol due to the inability to send heartbeats
over unicast or the inability to communicate with other DataReaders that have not been
configured to use a multicast receive address.
This issue is introduced in 6.1.0 and fixed in releases 6.1.2 and 7.1.0.
[RTI Issue ID CORE-12772]
8.7.1.2.3. No more than 100 asynchronous publisher threads can be created
A change to the thread-naming convention inadvertently limits the number of asynchronous publisher threads to 100. This limitation is fixed in releases 6.1.2 and 7.1.0. The limit is now 65,536 in those releases. These limits also apply to receive threads, asynchronous waitset threads, and persistence service threads.
[RTI Issue ID CORE-12874]
8.7.1.2.4. Creating DynamicDataTypePlugin with TypeCode from discovery and using content filtering causes segmentation fault
This regression was introduced in 6.0.0 and has been fixed in 6.0.1.30, 6.1.2, and 7.1.0. See Creating DynamicDataTypePlugin with TypeCode from discovery and using content filtering causes segmentation fault in the 6.0.0 Regressions section.
8.7.1.2.5. Crash with NULL listeners and non-none status masks in C applications that mix types with and without Zero Copy
This regression was introduced in 6.0.0 and has been fixed in 6.0.1.30, 6.1.2, and 7.1.0. See Section 8.9.1.1.2 in the 6.0.0 Regressions section.
8.7.1.2.6. Application using Monitoring Libraries produces segmentation fault during DataReader creation
This regression was introduced in 6.0.0 and has been fixed in releases 7.1.0 and 6.1.2. See Section 8.9.1.1.3 in the 6.0.0 Regressions section.
8.7.1.3. Fixed in 7.0.0 and 6.1.2
8.7.1.3.1. Continuous creation of TopicQueries may lead to unnecessary memory fragmentation in OS memory allocator
This regression was introduced in 6.0.0 and has been fixed in releases 7.0.0 and 6.1.2. See Continuous creation of TopicQueries may lead to unnecessary memory fragmentation in OS memory allocator in the 6.0.0 Regressions section.
8.7.1.4. Fixed in 6.1.1
8.7.1.4.1. Linking static Linux or QNX libraries with object files built with -fPIC will fail
In 6.1.0, RTI no longer builds Linux or QNX static libraries with the -fPIC
flag
(whereas previously RTI did build with this flag). Therefore, you cannot
link Linux or QNX static libraries in 6.1.0 with object files built with the -fPIC
flag. You will likely run into this problem if you use the static Linux or QNX library
in 6.1.0 while building a shared library.
This problem is fixed in release 6.1.1. See Potential -fPIC flag issue when using static libraries in Linux and QNX if upgrading from 6.1.0.
[RTI Issue ID PLATFORMS-2519]
8.7.1.4.2. XSD Issue: order enforced in <publisher> tag
This regression was introduced in 6.0.0 and has been fixed in release 6.1.1. See XSD issue: order enforced in <publisher> tag in the 6.0.0 Regressions section.
8.7.1.4.3. Invalid key deserialization for mutable derived types with key members
This regression was introduced in 6.0.0 and has been fixed in release 6.1.1. See Invalid key deserialization for mutable derived types with key members in the 6.0.0 Regressions section.
8.7.1.4.4. Malformed samples with invalid strings not dropped by DataReader in C, traditional C++, and modern C++
This regression was introduced in 6.0.0 and has been fixed in release 6.1.1. See Malformed samples with invalid strings not dropped by DataReader in C, traditional C++, and modern C++ in the 6.0.0 Regressions section.
8.7.1.4.5. 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 been fixed in release 6.1.1. 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.
8.7.1.4.6. XML parser crashed from infinite recursion when XML QoS configuration contained inheritance loop
This regression was introduced in 6.0.1 and has been fixed in release 6.1.1. See XML parser crashed from infinite recursion when XML QoS configuration contained inheritance loop in the 6.0.1 Regressions section.
8.7.1.4.7. 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 betweenm1
andm2
inMyType
.
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 is fixed in release 6.1.1.
[RTI Issue ID CORE-11604]
8.7.1.4.8. Possible segmentation fault when receiving samples containing wstrings
This regression was introduced in releases 6.0.1.22 and 6.1.0.3, and has been fixed in 6.1.1. See Possible segmentation fault when receiving samples containing wstrings in the 6.0.1 Regressions section.
8.7.1.4.9. 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.
If your application uses MultiChannel DataWriters, please contact support@rti.com to get a patch.
This problem has been resolved in release 6.1.1.
[RTI Issue ID CORE-11742]
8.7.1.4.10. Significant performance regression on Windows when using OpenSSL 1.1.1 libraries in 6.1.0
See Section 8.7.5.2.1 below.
8.7.1.4.11. ReadCondition may incorrectly stay enabled after sample in READ sample state removed from the DataReader’s queue
This regression was introduced in 6.1.0.
There are certain scenarios that cause a ReadCondition that is enabled when
samples are in the READ_SAMPLE_STATE
or ANY_SAMPLE_STATE
to stay enabled
forever. This happens if a sample that previously has been read by the application
is removed from the DataReader’s queue, for example, due to KEEP_LAST
history
replacement.
This issue causes any Waitset to which the ReadCondition is attached to immediately return successfully even though there actually aren’t any samples available in the DataReader’s queue that match the ReadCondition.
This issue only affects keyed data types. This issue has been fixed in 6.1.1. In 6.1.1, the ReadConditions will correctly be disabled once there are no more samples in the DataReader’s queue that match its configured sample, view, and instance states.
[RTI Issue ID CORE-12168]
8.7.1.4.12. Missing SampleInfo.ReceptionTimestamp property (C# API only)
The new Connext C# API introduced in 6.1.0 did not provide the
SampleInfo.ReceptionTimestamp
extension property. This property has been
added in 6.1.1.
[RTI Issue ID CORE-11908]
8.7.2. Code Generator
8.7.2.1. Fixed in 7.1.0
8.7.2.1.1. Compile-time error when using -constructor with types containing sequence of pointers
After release 6.0.1, if you create an IDL with a sequence of pointers, and
generate code for C++98 with the -constructor
flag, you encounter a
compile-time error, because Code Generator assigns NULL to the sequence. This
problem is fixed in release 7.1.0. As of 7.1.0, the code now generates the
constructor correctly when using a sequence of pointers.
[RTI Issue ID CODEGENII-1596]
8.7.2.2. Fixed in 6.1.1
8.7.2.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 been fixed in release 6.1.1. 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.
8.7.2.2.2. Invalid key deserialization for mutable derived types with key members
See Invalid key deserialization for mutable derived types with key members in the 6.0.0 Regressions section.
8.7.2.2.3. Malformed samples with invalid strings not dropped by DataReader in C, traditional C++, and modern C++
See Malformed samples with invalid strings not dropped by DataReader in C, traditional C++, and modern C++ in the 6.0.0 Regressions section.
8.7.2.2.4. Invalid serialization of samples with types containing nested structures with primitive members that require padding
8.7.3. Admin Console
8.7.3.1. Fixed in 6.1.1
8.7.3.1.1. High CPU usage by Admin Console
This regression was introduced in 6.1.0. Admin Console incorrectly identified too many fields as participating in the key of the data type. Also, the Instance Table view attempted to add all key fields as columns. If this behavior was combined with finding too many keys, Admin Console experienced high CPU consumption. This issue has been resolved in release 6.1.1.
[RTI Issue ID ADMINCONSOLE-995]
8.7.4. TLS Support
8.7.4.1. Fixed in 6.1.1
8.7.4.1.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 are fixed in release 6.1.1.
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]
8.7.4.1.2. Significant performance regression on Windows when using OpenSSL 1.1.1 libraries in 6.1.0
See Section 8.7.5.2.1 below.
8.7.5. Security Plugins
8.7.5.1. Fixed in 7.2.0
8.7.5.1.1. Discovery time scaled poorly
This regression was introduced in 6.0.0 and has been fixed in 7.2.0. See Discovery time scaled poorly in the 6.0.0 Regressions section.
8.7.5.2. Fixed in 6.1.1
8.7.5.2.1. Significant 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 6.1.0 are 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 6.0.1.22 can be used instead.
This problem has been fixed in release 6.1.1.
[RTI Issue ID SEC-1458]
8.7.5.2.2. use_530_partitions incorrectly allowed any non-empty partitions
If access_control.use_530_partitions
is set to true, then an allow_rule
with at least one partition always allows an endpoint with at least one partition
as long as the rule’s topic and the endpoint’s topic are compatible. This behavior
is incorrect because if access_control.use_530_partitions
is set to true, an
endpoint with QoS partitions should only be allowed if any of them match the
partition rule. For example, an allow rule with <partition>P*</partition>
should
not allow an endpoint with partition “R”.
This problem only affected Security Plugins 6.0.1.20 and 6.1.0, and has been fixed in 6.1.1.
[RTI Issue ID SEC-1544]
8.7.5.2.3. 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
This problem has been fixed in release 6.1.1.
[RTI Issue ID SEC-1428]
8.7.6. Routing Service
8.7.6.1. Fixed in 6.1.1
8.7.6.1.1. Unbounded memory growth when restarting Service or creating/deleting DomainRoutes
This regression occurred in 6.0.0 and has been fixed in release 6.1.1. See Unbounded memory growth when restarting Service or creating/deleting DomainRoutes in the 6.0.0 Regressions section.
8.7.6.1.2. Crash in Routing Service executable when providing the same -Dname=value pair twice
This regression occurred in 6.1.0 and has been fixed in release 6.1.1
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 is fixed in release 6.1.1.
[RTI Issue ID ROUTING-881]
8.7.7. Recording Service
8.7.7.1. Fixed in 7.1.0
8.7.7.1.1. Exception reported when recording or replaying type registered as a union
Publishing a union type instead of a structure type caused Recording Service to report an exception. Previously, a union was a valid type for Recording Service. This problem is fixed in 7.1.0.
[RTI Issue ID RECORD-1339]