5.6.19. Hangs

5.6.19.1. [Critical] String built-in type unregister_type API blocked associated DomainParticipant

The unregister_type for the String built-in type did not work properly; it failed and blocked the DomainParticipant instead of unregistering the type.

[RTI Issue ID CORE-14543]

5.6.19.2. [Critical] Potential deadlock when using SHMEM transport on Linux, macOS, and LynxOS systems and killing one application

Consider the following scenario:

  • Three applications using the the SHMEM transport are communicating with each other.

  • One application is ungracefully killed while creating a DomainParticipant.

If the killing of the application occurred at just the wrong moment, then the other applications would stop communicating with each other because they were in a deadlock. The deadlock would persist until you cleaned the shared memory resources. In addition, any new DomainParticipants that attempted to use the same shared memory resources as the killed application would hang during DomainParticipant creation.

The problem could occur in Linux®, macOS®, and LynxOS® systems.

Now, instead of entering a deadlock, Connext will print a log message like this one at the WARNING level and the PLATFORM category:

RTIOsapiSharedMemorySemMutex_attach_os:FAILED TO ATTACH | Semaphore set identifier 0x12345678 has not been initialized. Consider cleaning this semaphore if this warning occurs multiple times for this semaphore across all applications on this machine.

The semaphore set identifier corresponds to the semid column of the output of ipcs -s on Linux:

------ Semaphore Arrays --------
key        semid      owner      perms      nsems
0x0010000c 305419896  username   666        1

[RTI Issue ID CORE-14848]

5.6.19.3. [Critical] Potential deadlock when creating entities in parallel that use Zero Copy transfer over shared memory transport

Consider the following scenario:

  • A DomainParticipant is using the Zero Copy transfer over shared memory transport.

  • One thread is trying to create a DataWriter or DataReader belonging to that DomainParticipant.

  • Another thread is either:

    • trying to create a DataWriter or DataReader from a callback function of a builtin Topic DataReader belonging to that DomainParticipant, or

    • using the Request-Reply API and trying to create a Requester or Replier belonging to that DomainParticipant.

These two threads may have entered a deadlock while trying to create their entities.

[RTI Issue ID CORE-14820]

5.6.19.4. [Major] Running out of memory during DomainParticipant creation caused DomainParticipantFactory finalization to hang

During DomainParticipant creation, if the internal function REDAWorkerFactory_createWorker() runs out of memory and prints this error:

REDAWorkerFactory_createWorker:no space on heap for array with 1024 elements of size 8 bytes

then DomainParticipant creation will fail. The problem was that when you later tried to finalize the DomainParticipantFactory, this operation would hang and repeatedly print these errors:

REDAWorkerFactory_destroyWorkerEx:!take mutex

This problem only affected versions 7.0.0 to 7.3.0.

[RTI Issue ID CORE-14962]