10.8. Regressions in 6.1.0
The following regressions were introduced in Connext 6.1.0.
10.8.1. Core Libraries
10.8.1.1. Possible to create a DomainParticipant in a DomainID > 232 without getting error or warning
Connext does not properly validate the computed port numbers derived from the
Domain ID, Participant ID, and rtps_well_known_ports parameters. This can
result in port values exceeding the maximum allowed by the uint16_t type
(65535). When this occurs, the port number is silently truncated,
potentially causing port collisions and allowing invalid Domain IDs (for
example, values greater than 232) to be used.
Not fixed yet
[RTI Issue ID CORE-13448]
10.8.1.2. Segmentation fault if application runs out of memory while generating a log message
If the application runs out of memory while generating a log message,
then the application crashes with a segmentation fault in the
internal function ADVLOGLogger_destroyMessageQueueElement.
Fixed in: 7.5.0
[RTI Issue ID CORE-15432]
10.8.1.3. Possible memory leak when initializing and finalizing the DomainParticipantFactory concurrently
If one thread is initializing the DomainParticipantFactory (e.g., by calling
DDSDomainParticipantFactory::get_instance() in traditional C++) and another
thread is 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 wisas possible due to a race
condition. This problem does not lead to unbounded memory growth.
Fixed in: 7.4.0
[RTI Issue ID CORE-14972]
10.8.1.4. max_samples resource limit not honored in some cases when using an unkeyed Topic and TopicQueries
If a DataReader creates multiple TopicQueries and has a finite max_samples resource limit, that limit is not correctly enforced in TopicQuery queues. After some time, the DataReader might accept more samples than max_samples or fail to allocate more samples, leading to errors and lost samples. This only happens if the Topic is unkeyed. This issue has been fixed. Now, when a DataReader issues multiple TopicQueries, the max_samples resource limit is properly enforced for each TopicQuery queue.
Fixed in: 7.3.0
[RTI Issue ID CORE-14363]
10.8.1.5. 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).)
Fixed in: 6.1.2, 7.1.0
[RTI Issue ID CORE-12739]
10.8.1.6. Broken communication when DataWriter with transport priority discovers DataReader with multicast receive address
If a DataWriter that has a non-default DataWriterQos.transport_priority value set
discovers a DataReader with a multicast receive address, the DataWriter, and any other
DataWriter within the same participant, is not able to send any traffic over unicast.
This can 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.
Fixed in: 6.1.2, 7.1.0
[RTI Issue ID CORE-12772]
10.8.1.7. 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 has been fixed; the limit is now 65,536 in the fixed releases. These limits also apply to receive threads, asynchronous waitset threads, and persistence service threads.
Fixed in: 6.1.2, 7.1.0
[RTI Issue ID CORE-12874]
10.8.1.8. 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. See Potential -fPIC flag issue when using static libraries in Linux and QNX if upgrading from 6.1.0.
Fixed in: 6.1.1
[RTI Issue ID PLATFORMS-2519]
10.8.1.9. Invalid serialization of samples with types containing nested structures with primitive members that require padding
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 (
MyTypeabove) and the nested type containing only primitive members (MyType2above) are appendable or final.There is a padding in the equivalent C/C++ type between the nested type member (
m2above) and the previous member (m1above). In the above example, there is a 4-byte padding betweenm1andm2inMyType.
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.
Fixed in: 6.1.1
[RTI Issue ID CORE-11604]
10.8.1.10. 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.
Fixed in: 6.1.1
[RTI Issue ID CORE-11742]
10.8.1.11. Significant performance regression on Windows when using OpenSSL 1.1.1 libraries in 6.1.0
See Section 10.8.5.1 below.
10.8.1.12. ReadCondition may incorrectly stay enabled after sample in READ sample state removed from the DataReader’s queue
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. Now, 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.
Fixed in: 6.1.1
[RTI Issue ID CORE-12168]
10.8.1.13. Missing SampleInfo.ReceptionTimestamp property (C# API only)
The new Connext C# API introduced in 6.1.0 does not provide the
SampleInfo.ReceptionTimestamp extension property.
Fixed in: 6.1.1
[RTI Issue ID CORE-11908]
10.8.1.15. Significant performance regression on Windows systems when using OpenSSL 1.1.1k libraries provided 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 libraries for Windows systems, provided with Connext 6.1.0, are missing those compiler flags. This results in degraded performance in Secure WAN Transport and in TLS Support for the TCP transport, which rely on those libraries.
This issue is resolved with an upgrade to OpenSSL 1.1.1n in 6.1.1.
Fixed in: 6.1.1
[RTI Issue ID COREPLG-564 and COREPLG-565]
10.8.1.16. Support removed for ARMv8 and x64 processors, cxx and gpp compilers, for QNX platform
In 6.1.0, support for QNX7 ARMv8 and x64 is unintentionally removed
from FindRTIConnextDDS.cmake. As a result, when you try to
cross-compile to QNX (ARMv8 or x64 architectures) an error appears:
"<architecture> architecture is unsupported by this module"
Fixed in: 6.1.2, 7.0.0
[RTI Issue ID INSTALL-677]
10.8.1.17. Support removed for ARMv8 Linux architecture
In 6.1.0, support for Linux ARMv8 is unintentionally removed from
FindRTIConnextDDS.cmake. As a result, when you try to cross-compile,
an error appears:
"<architecture> architecture is unsupported by this module"
Fixed in: 6.1.2, 7.0.0
[RTI Issue ID INSTALL-675]
10.8.2. Code Generator
10.8.2.1. Generated code may contain mixed line breaks
Generated code may contain mixed line breaks, which can trigger warnings in Visual Studio compilers.
Not fixed yet
[RTI Issue ID CODEGENII-1515]
10.8.2.2. @default annotation for wstring members in C++11 is not applied
When generating code for C++11, the @default annotation for
wstring members is not applied.
Fixed in: 7.5.0
[RTI Issue ID CODEGENII-2159]
10.8.2.3. Java subscriber may not preserve union discriminator value, when discriminator is enum
A Java subscriber does not preserve the discriminator value when the discriminator is an enumerator and the following is true:
The discriminator value does not point to a known branch in the union, nor in the DataReader or DataWriter.
The data representation is XCDR (not XCDR2).
The type is appendable.
The subscriber also does not reject, by default, a discriminator value that points to a branch in the DataWriter instead of the DataReader when the data representation is XCDR2.
Fixed in: 7.3.0
[RTI Issue ID CODEGENII-1979]
10.8.2.4. 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.
The code now generates the constructor correctly when using a sequence of
pointers.
Fixed in: 7.1.0
[RTI Issue ID CODEGENII-1596]
10.8.2.5. Invalid serialization of samples with types containing nested structures with primitive members that require padding
10.8.2.6. Invalid code generated for unions in C++98
The C++98 code generated for unions is wrong and does not compile. For example:
union myUnion switch(int32) {
case 1:
long myLong;
case 2:
short myShort;
default:
float myFloat;
};
Fixed in: 6.1.1
[RTI Issue ID CODEGENII-1586]
10.8.3. Admin Console
10.8.3.1. High CPU usage by Admin Console
Admin Console incorrectly identifies too many fields as participating in the key of the data type. Also, the Instance Table view attempts to add all key fields as columns. If this behavior is combined with finding too many keys, Admin Console experiences high CPU consumption.
Fixed in: 6.1.1
[RTI Issue ID ADMINCONSOLE-995]
10.8.3.2. Admin Console does not correctly delete Publisher and Subscriber entities
There is a problem that causes the Publisher and Subscriber entities discovered by Admin Console to remain created in the different Admin Console views even when they are no longer present in the system. In the fix for this issue, Publisher and Subscriber entities are correctly removed.
Fixed in: 6.1.1
[RTI Issue ID ADMINCONSOLE-1000]
10.8.4. TLS Support
10.8.4.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.
As a workaround, you may use the certificates from dds_security/cert/dtls_rsa01
instead of dds_security/cert/tls_rsa01.
Fixed in: 6.1.1
[RTI Issue ID COREPLG-554]
10.8.4.2. Significant performance regression on Windows when using OpenSSL 1.1.1 libraries in 6.1.0
See Section 10.8.5.1 below.
10.8.5. Security Plugins
10.8.5.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.
Fixed in: 6.1.1
[RTI Issue ID SEC-1458]
10.8.5.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”.
Fixed in: 6.1.1
[RTI Issue ID SEC-1544]
10.8.5.3. Permissions document incorrectly disallows unescaped special characters in a subject name
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
Fixed in: 6.1.1
[RTI Issue ID SEC-1428]
10.8.6. Routing Service
10.8.6.1. Routing Service Socket Adapter example does not properly resolve hostname
The Routing Service Socket Adapter example incorrectly handles the
result of the RTIOsapiSocket_getHostByName() function. This could result in
hostname resolution errors.
Fixed in: 7.3.0
[RTI Issue ID ROUTING-1137]
10.8.6.2. 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.
Fixed in: 6.1.1
[RTI Issue ID ROUTING-881]
10.8.7. Recording Service
10.8.7.2. Exception reported when recording or replaying type registered as a union
Publishing a union type instead of a structure type causes Recording Service to report an exception. Previously, a union was a valid type for Recording Service.
Fixed in: 7.1.0
[RTI Issue ID RECORD-1339]
10.8.7.3. Replay Service’s Monitoring ServicePeriodic topic shows wrong timestamp
During Replay, the Monitoring ServicePeriodic topic publishes the wrong
timestamp. Its field current_timestamp_nanos is incorrectly set to the
current system time. Instead, it should be set to the timestamp
at which the data is replayed, relative to the recorded time.
In the fix for this issue, current_timestamp_nanos shows the correct
timestamp, so you can understand where you are in the replay.
Fixed in: 6.1.1
[RTI Issue ID RECORD-1277]
10.8.8. Cloud Discovery Service
10.8.8.1. Restricting domains using command-line arguments requires use of both -allowDomain and -denyDomain arguments
The -allowDomain and -denyDomain command line
arguments
for Cloud Discovery Service allow you to restrict which domains the
service operates on. The
XML
tag equivalents (<allow_domain_id> and <deny_domain_id>) allow
use of just one of these tags, while the other tag uses its default; the
same is not true for the command-line arguments.
This leads to a usability inconsistency where using the command-line
arguments -allowDomain and -denyDomain require use of both tags
at the same time; otherwise, the values passed are not applied. This issue
has been fixed. Now, using any one of the arguments causes
the other argument to use its default, while the passed value is applied
correctly.
Fixed in: 7.3.0
[RTI Issue ID CDS-183]