5.2.19. Hangs

5.2.19.1. [Critical] Calling ignore_participant during a ParticipantBuiltinTopicDataDataReader on_data_available callback triggered by the deletion of a remote DomainParticipant led to a hang or unexpected error message

Suppose you were following the example code in Ignoring Specific Remote DomainParticipants for ignoring a DomainParticipant during a ParticipantBuiltinTopicDataDataReader on_data_available callback. When the callback was invoked as a result of deleting a DomainParticipant, it was possible for this ignore_participant to misbehave under either of the following conditions:

  • You had called set_listener on the ParticipantBuiltinTopicDataDataReader after enabling the DomainParticipant.

  • In a previous invocation of the on_data_available callback, you had not taken all of the samples, so in this invocation, there are multiple samples to take.

The misbehavior was as follows:

  • In release libraries, ignore_participant would have succeeded, but a later call of DDS_DomainParticipant_delete_contained_entities would have hanged.

  • In debug libraries, ignore_participant would have succeeded but with an error message in the internal function REDACursor_startFnc.

This problem has been fixed by making ignore_participant succeed without any side effects.

[RTI Issue ID CORE-15558]

5.2.19.2. [Critical] Potential deadlock when calling DDS_DomainParticipantFactory_set_qos and DDS_DomainParticipantFactory_finalize_instance

The application may have ended up in a deadlock in the following scenario:

  • A custom XML file contained a structure.

  • One thread called DDS_DomainParticipantFactory_set_qos while another thread called DDS_DomainParticipantFactory_finalize_instance at the same time.

[RTI Issue ID CORE-15541]

5.2.19.3. [Critical] Potential deadlock when using Network Capture utility APIs concurrently with DDS calls

Using the Network Capture utility APIs in one thread while making DDS calls in another thread could cause a deadlock during the first DDS API call in that thread.

The hang occurred because the creation of some DDS thread-specific state was taking a pair of locks in the opposite order in which they were taken by the Network Capture APIs.

[RTI Issue ID CORE-15984]

5.2.19.4. [Critical] Hang of QNX application using shared memory if one of the shared semaphores was in an unusable state

On QNX platforms, in the initialization of the shared memory transport, if a Connext application crashed or was killed between the creation and the initialization of a shared semaphore, that shared semaphore was unusable. Other Connext applications running on the same domain would try to access the shared semaphore and would hang waiting for the shared semaphore to be initialized. Now, the other Connext applications will log an error message and continue running if they wait for the shared semaphore initialization for more than four seconds.

[RTI Issue ID CORE-16108]

5.2.19.5. [Major] Calling ignore_participant when using the on_data_available callback to process a ParticipantBuiltinTopicData with partial_configuration led to a hang during DomainParticipant deletion

Suppose you were following the example code in Ignoring Specific Remote DomainParticipants for ignoring a DomainParticipant during a ParticipantBuiltinTopicDataDataReader on_data_available callback. When detecting the creation of another DomainParticipant, it was possible for this ignore_participant to misbehave when the ParticipantBuiltinTopicData::partial_configuration field was set to DDS_BOOLEAN_TRUE. The misbehavior was as follows:

  • In release libraries, ignore_participant would have succeeded, but a later call of DDS_DomainParticipant_delete_contained_entities would have hanged.

  • In debug libraries, ignore_participant would have succeeded but with an error message in the internal function REDACursor_startFnc.

This problem has been fixed by making ignore_participant succeed without any side effects.

[RTI Issue ID CORE-13783]