5.18. Crashes

5.18.1. [Critical] Potential crash when creating new GuardCondition when low on resources

In the Java API, the creation of a new GuardCondition could have led to a crash. This only happened when there was an issue in allocating native resources.

[RTI Issue ID CORE-14544]

5.18.2. [Critical] Parsing an XML file with a root “types” tag that contained a “name” attribute led to a segmentation fault

When Connext parsed an XML file with a root “types” tag, and that tag contained a “name” attribute, a segmentation fault occurred. The use of the name attribute in a root types tag is not permitted by the OMG ‘Extensible and Dynamic Topic Types for DDS’ specification, version 1.3, so this error would only occur with non-conforming XML files. Other non-conforming XML files, such as those with invalid root tags that contained elements with the name attribute, also caused this issue.

[RTI Issue ID CORE-14422]

5.18.3. [Critical] Parsing of malformed RTPS packages may have led to bus error in some platforms

Parsing malformed RTPS packages (with or without RTI Security Plugins) may have caused a bus error on QNX platforms running on an armv7 processor.

[RTI Issue ID CORE-14617]

5.18.4. [Critical] Potential race conditions in construction or deletion of Requesters and Repliers (C, Traditional C++, C#, and Python)

A race condition may have caused crashes or exceptions when constructing or deleting Requesters and Repliers in the C, Traditional C++, C#, and Python APIs.

These issues were previously fixed as RTI Issue IDs [REQREPLY-127] and [REQREPLY-132] for the Modern C++ and Java APIs.

[RTI Issue ID REQREPLY-133]

5.18.5. [Critical] Possible crash when creating dds.DynamicData.Topic with a listener

A crash in the Python API may have occurred while creating a dds.DynamicData.Topic with a listener. The problem did not occur if the listener was set after creating the topic with set_listener(). This problem did not affect IDL-based topics (dds.Topic).

[RTI Issue ID PY-159]

5.18.6. [Critical] Possible crash after a failure to create Monitoring Library 2.0 object

If RTI Monitoring Library 2.0 was enabled in your application, and something failed while creating the library object (for example, if the Monitoring Library 2.0 internal DDS entities could not be created because of an inconsistent QoS configuration), the system may have crashed.

The crash happened during clean-up after the failure, because some improperly initialized pointers were accessed. Before the crash, you may have seen errors in the RTI_Monitoring_create() function.

To prevent this crash, all the pointers are now initialized to NULL before calling RTI_Monitoring_create(). Note that, depending on how your platform handles pointers initialization, this might or might not be a problem.

[RTI Issue ID MONITOR-668]

5.18.7. [Critical] Possible segmentation fault while enabling a DataWriter that enables batching

Consider the following scenario:

You are using the Java API.
The DataWriterQos has batch.enable set to true.

Attempting to enable a DataWriter with that QoS would occasionally fail with a segmentation fault in the internal function PRESTypePluginDefaultEndpointData_calculateBatchBufferSize(). This problem only affected releases 7.0.0 to 7.3.0.

[RTI Issue ID CORE-14659]

5.18.8. [Critical] Segmentation fault when copying invalid samples and using Zero Copy transfer over shared memory transport

When reading or taking samples from a DataReader’s queue, the samples can either be loaned or copied from the queue, depending on which version of the read or take API is used and how it is used. When a DataReader that supported receiving samples over the Zero Copy transfer over shared memory transport used the read or take APIs that copied samples from the DataReader’s queue (instead of loaning them), the application crashed if any of the samples had the SampleInfo::valid_data flag set to false. The only safe APIs for copying samples from the DataReader’s queue were FooDataReader::read_next_sample() and FooDataReader::take_next_sample() because those APIs skip samples with the valid_data flag set to false.

[RTI Issue ID CORE-14442]

5.18.9. [Critical] Possible crash when calling DDS_DataWriter_get_matched_subscriptions() or DDS_DataReader_get_matched_publications() on architectures with a weak memory model

On architectures that use a weak memory model, such as Arm-based architectures, the application may have crashed when calling DDS_DataWriter_get_matched_subscriptions() or DDS_DataReader_get_matched_publications() (or their C++ equivalents) at the same time that a new matching entity was discovered. The crash happened in some rare cases due to a reordering of the memory storages. Now the mentioned APIs can be called at the same time that a new matching entity is discovered.

[RTI Issue ID CORE-14743]

5.18.10. [Critical] Possible crash when using QosProvider to load XML file with syntax `file:///` on Windows systems

This issue was fixed in 7.3.0, but not documented at that time.

When using a QosProvider to load profiles from a file, the documented syntax for specifying the file’s URL is to use three slashes: file:///. However, using the file:/// syntax caused a crash on Windows systems. The workaround was to use two slashes, file://.

To address this, both file:/// and file:// are now valid.

[RTI Issue ID CORE-14603]

5.18.11. [Critical] Crash on DDS_DomainParticipantFactory_finalize_instance() when using XML-Based Application Creation

When using XML-Based Application Creation with multiple registered types, DDS_DomainParticipantFactory_finalize_instance() could have crashed the JVM.

[RTI Issue ID CORE-14912]

5.18.12. [Critical] Parsing of malformed RTPS packets may have led to bus error on some platforms

Parsing malformed RTPS packets (with or without RTI Security Plugins) may have caused a bus error on QNX platforms running on an armv7 processor (this may not be the only platform affected). This was fixed and a malformed RTPS message is now dropped before causing the bus error.

[RTI Issue ID CORE-14549]

5.18.13. [Critical] Crash if element in initial_peers longer than 72 characters added

If a DomainParticipant had an element in the initial_peers longer than 72 characters, or if a peer longer than 72 characters was added using DDS_DomainParticipant_add_peer(), the program would crash. This problem has been resolved, and now peers up to 210 characters in length can be added. If a peer is added that is longer than 210 characters, the program will not crash, but the DomainParticipant will print the following set of errors:

DDS_DiscoveryQosPolicy_parseParticipantPeerDescriptor: locator string too long: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
ERROR [0x010134D9,0x574C97F0,0xE8BB2C8C:0x000001C1{Domain=0}|ADD_PEER BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB] DDS_DiscoveryQosPolicy_parsePeerDescriptorString:peer descriptor  format is unrecognized, string value = "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"
ERROR [0x010134D9,0x574C97F0,0xE8BB2C8C:0x000001C1{Domain=0}|ADD_PEER BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB] DDS_DomainParticipantDiscovery_add_peer:invalid peer descriptor

[RTI Issue ID CORE-14970]

5.18.14. [Major] Potential crash upon serialization, deserialization, or program shutdown when running out of memory

Serialization, deserialization, and program shutdown could have crashed if the program ran out of memory. The problem affected all APIs except Java. This situation will now fail gracefully, without crashing.

[RTI Issue ID CORE-14656]

5.18.15. [Major] Possible crash when closing a logger device while it was being used

Due to a concurrency issue in the Connext logging infrastructure, there was the small possibility of a crash in an application when a logger device was closed at the same time it was being used for logging a message.

[RTI Issue ID CORE-10546]

5.18.16. [Major] Crash during custom transport load when running out of memory

A Connext application could crash if it ran out of memory while loading a custom transport plugin. Now the load fails gracefully when running out of memory.

[RTI Issue ID CORE-14706]

5.18.17. [Major] Precondition failure or segmentation fault when nonBasicTypeName is the name of a module

When attempting to load an XML file used for creating user data types, a precondition failure or segmentation fault occurred if the value of nonBasicTypeName was the name of a module. For example, consider this invalid XML file:

<types>
<module name="tc2idl">
  <struct name= "TestData">
    <member name="aWStringSequenceSequence" type="nonBasic"  nonBasicTypeName= "tc2idl" arrayDimensions="3,4"/>
  </struct>
</module>
</types>

When attempting to load this XML file using the debug libraries for a 64-bit architecture, you would incorrectly get the following precondition error:

TypeCodeObject.c:140:RTI0x3000035:!precondition: "self == ((void *)0)"

This precondition error occurred because tc2idl is the name of a module, not the name of a struct, enum, bitset, typedef, valuetype, sparse_valuetype, or union.

When attempting to load this XML file using the release or debug libraries for a 32-bit architecture, you would get a segmentation fault in the function RTICdrTypeCode_hasCdrRepresentation.

When attempting to load this XML file using the release libraries for a 64-bit architecture, you would correctly get the following error:

DDS_XMLTypeCode_validateMemberTypeSymbol:Parse error at line 6: type 'tc2idl' is not a struct, enum, bitset, typedef, valuetype, sparse_valuetype or union

Now, you will get this error regardless of release or debug libraries and regardless of 32-bit or 64-bit architecture.

[RTI Issue ID CORE-14779]