How can I resolve problems with QNX applications that use shared memory?

Note: Applies to RTI Connext 4.x and above

If you have an RTI Connext application running on a QNX machine and it is unable to communicate with other applications running on the same machine started by another user, or if your application fails to start (with an error related to shared memory), then follow the recommendations below.

By default, QNX systems have the umask set so that other users are not allowed to reuse a shared memory handle. 

If you want to have shared-memory support between different users, run the command  umask 000 to change the default umask value to 0 before running your RTI Connext application. 

Another known issue is when your RTI Connext application hangs when starting up after killing it a couple of times with CTRL+C. This happens because while using POSIX, if your RTI Connext application is finished ungracefully while a semaphore is locked, the semaphore will remain locked. Therefore, when another RTI Connext application tries to take this semaphore, it waits until the semaphore is unlocked, but that will never happen, resulting in a deadlock. To avoid this problem, you need to clean up the shared memory segments in between runs.

To see a list of the shared memory resources, enter:

ls /dev/shmem/RTIOsapiSharedMemory*

To clean up the shared memory resources, remove the files listed under dev/shmem/RTIOsapiSharedMemory*. 

To see a list of shared semaphores, enter:

ls /dev/sem/RTIOsapiSharedMemory*

To clean up the shared semaphore resources, remove the files listed under /dev/sem/.

The shared resources used by RTI Connext begin with RTIOsapiSharedMemory*.