6.6.3. Fixes Related to Transports
6.6.3.1. [Critical] Communication problems with applications using shared memory on INTEGRITY systems
If an application on an INTEGRITY platform used the shared-memory transport, the Connext libraries sometimes incorrectly assessed that a shared-memory segment was stale and could be reclaimed, when in fact it was not stale.
This situation caused problems with communication between DomainParticipants, since information could be sent to a shared-memory segment that did not get dequeued by the intended recipient.
You may have seen error messages like these and the application may have hung while deleting the DomainParticipant:
<Target Output> ERROR RTIOsapiSharedMemoryBinarySemaphore_take:OS WaitForSemaphore() failure, error 0XD: ObjectClosed
<Target Output> ERROR NDDS_Transport_Shmem_receive_rEA:!take semaphore
<Target Output> ERROR RTIOsapiSharedMemoryBinarySemaphore_take:OS WaitForSemaphore() failure, error 0X9: ObjectIsUseless
This problem has been resolved.
[RTI Issue ID CORE-12097]
6.6.3.2. [Critical] Race condition could cause unbounded memory growth in TCP Transport Plugin
Due to a race condition, the TCP Transport Plugin may have leaked memory when creating a new connection if the creation happened at the same time the DomainParticipant was being destroyed. The cause of the leak was the TCP Transport Plugin reallocating memory that was already released by the DomainParticipant. The race condition was unlikely to happen. However, in a system that frequently creates and destroys entities (and, therefore, TCP connections) and that runs for long enough, it may have lead to unbounded memory growth. The issue has been resolved.
[RTI Issue ID COREPLG-618]