6.6.10. Other Fixes
6.6.10.1. [Critical] Serialization/deserialization of non-primitive sequences and arrays for XCDR2_DATA_REPRESENTATION did not follow Extensible Types specification
The serialization/deserialization of sequences and arrays with non-primitive members for XCDR2_DATA_REPRESENTATION did not follow the OMG ‘Extensible and Dynamic Topic Types for DDS’ specification, version 1.3. This led to compatibility issues with other DDS implementations.
This problem has been fixed, although the new behavior is not enabled by default, in order to keep backward compatibility with previous Connext releases. You can configure a DomainParticipant to align with the specification by setting dds.type_plugin.dheader_in_non_primitive_collections to true in the DomainParticipant’s PROPERTY QoS Policy for all the DomainParticipants created by your Connext applications.
[RTI Issue ID CORE-12464]
6.6.10.2. [Critical] Possible hang when using best-effort writers and asynchronous publishing
Due to an internal error, an application hung when using a best-effort writer and asynchronous publishing. Before the hang, the following error message was printed:
COMMENDBeWriterService_write:!retrieveJob
This problem is now fixed.
[RTI Issue ID CORE-12562]
6.6.10.3. [Critical] Runtime error when using debug libraries for QNX x86 platform
When using the i86QNX6.6qcc_cpp4.7.3 debug libraries, your application may have had a runtime error and hung. This was because the debug libraries included the symbol for a math function (“isinff”) that was discontinued in QNX 6.3.
This problem has been resolved. The debug libraries now include “isinf” instead, which is supported.
A full list of the math functions that were discontinued in QNX 6.3 can be found here: http://www.qnx.com/developers/docs/6.6.0.update/index.html#com.qnx.doc.neutrino.lib_ref/topic/whats_new_630.html.
Note: QNX platforms on x86 are not supported in Connext 7.0.0.
[RTI Issue ID CORE-12695]
6.6.10.5. [Critical] Potential truncation of application-level acknowledgment response data
Connext enforced a wrong maximum length for application-level acknowledgment response data. Specifically, Connext incorrectly allowed setting the DATA_READER_RESOURCE_LIMITS QosPolicy’s max_app_ack_response_length longer than the maximum serializable data, which resulted in the truncation of data when the length got close to 64kB.
This problem has been resolved: Connext now enforces a maximum length of 32kB for max_app_ack_response_length as part of DataReader QoS consistency checks, and it will log an error if you try to set max_app_ack_response_length longer than 32kB.
[RTI Issue ID CORE-12450]
6.6.10.6. [Critical] Potential Valgrind invalid read when logging a message or enabling heap monitoring
When activity context was enabled in logging, or when heap monitoring was enabled, a Valgrind invalid read similar to the following one may have been reported:
==1344490== Invalid read of size 4
==1344490== at 0x4A3FA0A: RTIOsapiActivityContext_skipResourceGuid (ActivityContext.c:246)
==1344490== by 0x4A417B3: RTIOsapiActivityContext_getString (ActivityContext.c:820)
This issue has been resolved. The Valgrind invalid read error no longer appears.
[RTI Issue ID CORE-12537]
6.6.10.7. [Major] Various issues with RtpsReliableWriterProtocol_t::nack_suppression_duration
There were various issues with the RtpsReliableWriterProtocol_t::nack_suppression_duration QoS:
NACKs were being incorrectly suppressed with asynchronous publishing or non-zero min/max_nack_response_delay if two NACK messages were received within the nack_suppression_duration window, even if they were NACKing for different sets of sequence numbers. The nack_suppression_duration is only meant to suppress NACKs with the same leading sequence number that are received within the nack_suppression_duration window. If two consecutive NACKs have different leading sequence numbers, this indicates that the reader is making progress and the second one should not be suppressed, regardless of the nack_suppression_duration. Incorrect suppression of NACKs was not an issue if min/max_nack_response_delay was zero and PublishModeQosPolicy.kind was SYNCHRONOUS_PUBLISH_MODE_QOS..
If a NACK was received and suppressed due to the nack_suppression_duration before the previous NACK was responded to, then the NACK that had not been responded to yet, along with all NACKs for the duration of the nack_suppression_duration, were incorrectly suppressed. This problem did not occur if min/max_nack_response_delay was zero and PublishModeQosPolicy.kind was SYNCHRONOUS_PUBLISH_MODE_QOS.
When PublishModeQosPolicy.kind was ASYNCHRONOUS_PUBLISH_MODE_QOS, if there were no GAP messages sent in response to a NACK, the nack_suppression_duration had no effect and NACKs were never suppressed. (GAP messages are sent to a DataReader to indicate that a sample or a set of samples are not meant for that DataReader. This can happen, for example, because the DataWriter has applied writer-side filtering or no longer has those samples in its queue.)
These issues have been resolved.
[RTI Issue ID CORE-12603]
6.6.10.8. [Major] Possible error message printed during Entity disposal
Upon the disposal of an entity, an error message from a callback associated with an event may have been printed. An excerpt of what the error may have looked like this:
ERROR [0x01013D3F,0x79453D76,0xA3558BB2:0x00000000|REMOVE REMOTE DR 0x01013D3F,0x79453D76,0xA3558BB2:0x80000007] OnReliableReaderActivityChangedCallback:An exception was thrown: Omg.Dds.Core.DdsException: DDS operation failed:
at Rti.Dds.NativeInterface.Helpers.ReturnCode.CheckResult(IntPtr result)
...
The disposal of entities has now been modified to ensure this error does not happen.
[RTI Issue ID CORE-12641]
6.6.10.9. [Major] Source IP on Spy was not correct when DataWriters with same Topic were on different machines
The source IP on Spy may not have been correct when DataWriters with the same Topic were on different machines. This issue has been fixed. Now the source IP is per Entity, not per Topic, and the output will look like this:
11:35:13 New reader from 10.200.130.20 : topic=""Example app"" type=""app""
11:35:18 New writer from 10.200.129.195 : topic=""Example app"" type=""app""
11:35:16 New writer from 10.200.130.3 : topic=""Example app"" type=""app""
11:42:58 New data from 10.200.129.195 : topic=""Example app"" type=""app""
11:42:58 New data from 10.200.130.3 : topic=""Example app"" type=""app""
11:43:00 New data from 10.200.129.195 : topic=""Example app"" type=""app""
11:43:00 New data from 10.200.130.3 : topic=""Example app"" type=""app""
[RTI Issue ID CORE-12169]
6.6.10.10. [Minor] Unbounded memory growth in Monitoring Library when creating and deleting endpoints
Each time a DataWriter or DataReader is created in an application that has RTI Monitoring Library enabled, a new instance is created in the DataWriters of the library. Since, by default, the maximum number of instances the DataWriter can handle is unlimited, and the instances of already deleted endpoints were not cleaned up automatically, unbounded memory growth was possible in the library’s DataWriters when constantly creating and deleting endpoints in an application that had Monitoring Library enabled.
This problem has been fixed by setting the writer_data_lifecycle::autopurge_disposed_instances_delay QoS to DDS_DURATION_ZERO by default in the DataWriters for the Monitoring Library. That way, disposed instances will be instantly cleared.
[RTI Issue ID MONITOR-244]
6.6.10.11. [Minor] Unexpected behavior when two threads crashed at the same time on Windows systems
When two threads crashed at the same time on Windows systems, Connext may have concurrently called the function SymInitialize() from DbgHelp from two crashing threads.
SymInitialize() is not thread safe, so the application may have run into unexpected behavior or memory corruption under this scenario.
This has been resolved, Connext no longer calls SymInitialize() from a crashing thread. Instead, SymInitialize() is now called during DomainParticipantFactory initialization.
[RTI Issue ID CORE-10066]
6.6.10.12. [Minor] DataReaders setting reader_qos.protocol.expects_inline_qos to TRUE incorrectly matched with DataWriters
Connext DataWriters matched DataReaders that set reader_qos.protocol.expects_inline_qos to TRUE. This behavior was incorrect because Connext DataWriters do not support sending inline QoS, and they were not honoring the DataReaders’ requests.
This issue has been fixed. The behavior has changed so that DataWriters will not match DataReaders that request inline QoS (i.e., that set reader_qos.protocol.expects_inline_qos to TRUE).
[RTI Issue ID CORE-10501]
6.6.10.13. [Minor] Writer using durable writer history may not have blocked after send window filled up when disable positive ACKs was enabled
In previous releases, a reliable DataWriter configuring a finite send window size may not have blocked when the send window filled up if all these conditions were met:
DataWriter was configured to use durable writer history.
DataWriter was configured to use disable positive ACKs.
DataWriter was configured with writer_qos.reliability.acknowledgment_kind set to AUTO or EXPLICIT, or writer_qos.availability.enable_required_subscriptions was set to TRUE.
Because of this issue, the reliability protocol for the DataWriter may have been less efficient. This problem has been resolved.
[RTI Issue ID CORE-12225]
6.6.10.14. [Trivial] Error messages displayed that should not have been, when printing DataReaderQoS objects
When printing DataReaderQoS objects, and the contained DDSOwnershipQosPolicy or DDS_TransportMulticastQosPolicy policies were printed, some error messages were displayed that should not have been. These error messages could have been safely ignored by an application. These error messages are no longer printed.
[RTI Issue ID CORE-12462]
6.6.10.15. [Trivial] Unnecessary sockets created during initialization of library
The initialization of the Connext libraries always created a socket to obtain the IP address of the first valid interface of the machine. This IP address is used to generate identifiers when DDS_DomainParticipantQos::wire_protocol::rtps_auto_id_kind is DDS_RTPS_AUTO_ID_FROM_IP, which is not the default value. Therefore, the creation of this socket was unnecessary in most cases. This problem has been solved, and now the socket is only created when it is needed.
[RTI Issue ID CORE-12587]
6.6.10.16. [Trivial] Malformed IDL printed if multiple labels used for default case of a union
The IDL produced by the C API’s DDS_TypeCode_print_IDL() function (or the equivalent in other APIs) may have been malformed if multiple labels were assigned to the default case of a union. All of the labels were printed as “default: “, instead of their true value. This problem has been resolved.
[RTI Issue ID CORE-12624]