.. include:: /../getting_started/vars.rst .. _section-Regressions610: Regressions in 6.1.0 ******************** The following regressions were introduced in *Connext* 6.1.0. Core Libraries ============== Segmentation fault if application ran out of memory while generating a log message ---------------------------------------------------------------------------------- If the application ran out of memory while generating a log message, then the application would crash with a segmentation fault in the internal function ``ADVLOGLogger_destroyMessageQueueElement``. **Fixed in:** 7.5.0 [RTI Issue ID CORE-15432] .. _CORE-14972: Possible memory leak when initializing and finalizing the |DPF_HEADING| concurrently ------------------------------------------------------------------------------------ If one thread was initializing the |DPF| (e.g., by calling ``DDSDomainParticipantFactory::get_instance()`` in traditional C++) and another thread was finalizing the |DPF| (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. **Fixed in:** 7.4.0 [RTI Issue ID CORE-14972] 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] .. _CORE-12739: DomainParticipant with non-default metatraffic_transport_priority QoS does not complete discovery ------------------------------------------------------------------------------------------------- A |DP| 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] .. _CORE-12772: Broken communication when DataWriter with transport priority discovers DataReader with multicast receive address ---------------------------------------------------------------------------------------------------------------- If a |DW| that had a non-default ``DataWriterQos.transport_priority`` value set discovered a |DR| with a multicast receive address, the |DW|, and any other |DW| 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 |DRs| that have not been configured to use a multicast receive address. **Fixed in:** 6.1.2, 7.1.0 [RTI Issue ID CORE-12772] .. _CORE-12874: 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] .. _section-PLATFORMS-2519: 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 :ref:`section-MG-69-611`. **Fixed in:** 6.1.1 [RTI Issue ID PLATFORMS-2519] .. _section-CORE-11604: 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 |DR| may receive an invalid value for a sample. For example: .. code-block:: omg-idl 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. **Fixed in:** 6.1.1 [RTI Issue ID CORE-11604] 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 |DWs|. Release 6.1.0 introduced a regression in which a |DR| ends up subscribing to all the multicast addresses associated with a |DW|'s channels instead of subscribing to only the multicast addresses that can provide samples that pass the |DR| ContentFilteredTopic. Note that this issue does not affect correctness, because the |DR| ends up filtering locally the samples that did not pass its ContentFilteredTopic expression. If your application uses MultiChannel |DWs|, please contact support@rti.com to get a patch. **Fixed in:** 6.1.1 [RTI Issue ID CORE-11742] Significant performance regression on Windows when using OpenSSL 1.1.1 libraries in 6.1.0 ----------------------------------------------------------------------------------------- See :numref:`section-SEC-1458` below. 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 |DR|'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 |DR|'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 |DR|'s queue that match its configured sample, view, and instance states. **Fixed in:** 6.1.1 [RTI Issue ID CORE-12168] 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. **Fixed in:** 6.1.1 [RTI Issue ID CORE-11908] Code Generator ============== .. _CODEGENII-2159: @default annotation for wstring members in C++11 was not applied ---------------------------------------------------------------- When generating code for C++11, the ``@default`` annotation for wstring members was not applied. **Fixed in:** 7.5.0 [RTI Issue ID CODEGENII-2159] 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] .. _CODEGENII-1596: 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] Invalid serialization of samples with types containing nested structures with primitive members that require padding -------------------------------------------------------------------------------------------------------------------- See :ref:`section-CORE-11604` above. Admin Console ============= 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. **Fixed in:** 6.1.1 [RTI Issue ID ADMINCONSOLE-995] TLS Support =========== 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: .. code-block:: text 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: .. code-block:: text 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] Significant performance regression on Windows when using OpenSSL 1.1.1 libraries in 6.1.0 ----------------------------------------------------------------------------------------- See :numref:`section-SEC-1458` below. |RTI_SP_PRODUCT_HEADING| ======================== .. _section-SEC-1458: 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 |RTI_SP_PRODUCT|, *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] 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 ``P*`` should not allow an endpoint with partition "R". **Fixed in:** 6.1.1 [RTI Issue ID SEC-1544] Permissions document incorrectly disallowed unescaped special characters in a subject name ------------------------------------------------------------------------------------------ If a ```` 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: .. code-block:: xml CN=/common/name then *DomainParticipant* creation will fail with the following errors: .. code-block:: console 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, .. code-block:: xml CN="a, TwitterHandle=@guy" 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 .. code-block:: console openssl x509 -in -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 |SP_GSG|, 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 |SP_GSG|, .. code-block:: console openssl ca -config ca/pmiIdentityCa.cnf -days 730 -in identities/pmiAlice.csr -out identities/pmiAliceCert.pem would be changed to .. code-block:: console 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] Routing Service =============== 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] 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: .. code-block:: console >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: .. code-block:: text 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:\\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] Recording Service ================= .. _RECORD-1462: tags did not work for Topic groups --------------------------------------------------- *Recording Service* allows the use of ```` tags within Topic group configurations. These tags are mistakenly ignored by the service. **Fixed in:** 7.4.0 [RTI Issue ID RECORD-1462] .. _RECORD-1339: 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*. **Fixed in:** 7.1.0 [RTI Issue ID RECORD-1339] Cloud Discovery Service ======================= 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 (```` and ````) 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]