5.19. Hangs

5.19.1. [Critical] Undefined behavior when using SHMEM transport in Linux, macOS, QNX, INTEGRITY, and LynxOS

There was an issue in the SHMEM transport implementation that may have led to undefined behavior in your Connext application, including data corruption, errors, and hangs.

When the undefined behavior was a hang, you may have seen the following stack trace in some of the threads in your process:

#1 0x00007f42d1348d39 in RTIOsapiSharedMemorySemMutex_take_os () from libnddscore.so
#2 0x00007f42d134938f in RTIOsapiSharedMemorySemMutex_take () from libnddscore.so
#3 0x00007f42d14a468a in NDDS_Transport_Shmem_send () from libnddscore.so

The problem could occur on the following platforms: Linux, macOS, QNX, INTEGRITY, and LynxOS.

[RTI Issue ID CORE-12923]

5.19.2. [Major] Possible deadlock related to failures in DNS Tracker

In some cases there could have been a deadlock after an error occurred starting the DNS tracker or removing a hostname from an internal list. The error conditions were not handled appropriately, and a lock which had been previously taken was never released.

[RTI Issue ID CORE-13813]

5.19.3. [Critical] Segmentation fault or hang when using SHMEM transport on VxWorks 6 or higher platforms

A local DomainParticipant in a Connext application on a VxWorks 6 or higher platform, using the shared memory transport, may have generated a segmentation fault or hang when a remote DomainParticipant communicating with the local DomainParticipant was deleted or lost its liveliness. If you configured individual DataWriters and DataReaders on the remote DomainParticipant to use their own receive port using the TransportUnicastQosPolicy and TransportMulticastQosPolicy, the problem could have also occurred when you deleted these DataReaders or DataWriters.

In some cases, before the segmentation fault or hang, you may have seen the following error message:

RTIOsapiSharedMemorySegment_detach:OS sdUnmap() failure, error 0XBE000A: S_sdLib_NOT_MAPPED

[RTI Issue ID CORE-14041]