POSH__SHM_APP_MAPP_ERR

[owny990312]

I want to ask why the program is cored dump

what is the mean of this picture

[elBoberido]

@owny990312 it means that the application tried to open a specific shared memory but it did not exist. This can happen if for some reasons RouDi could not create the shared memory, RouDi was shot down in between and for some reasons did not terminate the registered applications or someone deleted the shared memory manually before the application was able to open the shared memory.

Which iceoryx version are you using?

[owny990312]

@owny990312 it means that the application tried to open a specific shared memory but it did not exist. This can happen if for some reasons RouDi could not create the shared memory, RouDi was shot down in between and for some reasons did not terminate the registered applications or someone deleted the shared memory manually before the application was able to open the shared memory.这意味着应用程序尝试打开一个特定的共享内存，但该共享内存不存在。这可能发生在 RouDi 由于某些原因无法创建共享内存、RouDi 在创建共享内存的过程中被关闭并且没有终止已注册的应用程序，或者有人在应用程序能够打开共享内存之前手动删除了共享内存。

Which iceoryx version are you using?你使用的是哪个 iceoryx 版本？

Thank you for your response. We are using version v2.0.6. We have found that issue #1761 describes the same problem we are experiencing. Could this be occurring because /dev/shm has been removed, or some other reason?

We've observed an interesting phenomenon: After starting RouDi and launching APP1, APP1 runs normally. Then, when we execute rm -rf /dev/shm and start APP2, it encounters the same error. Surprisingly, although /dev/shm has been deleted, APP1 continues to run - perhaps it's no longer writing data to shared memory at this point?

[elBoberido]

@owny990312 yes, deleting /dev/shm would lead to the problem you are experiencing.

At least with Linux, deleting a shared memory does not mean that it's fully gone. It's just not anymore accessible via the file system but Linux keeps the memory available as long as there are open file descriptors. This is the case, since RouDi as well as the running app still have the file descriptor to keep the shared memory alive. So, those who are already running will keep running but no new is able to participate in the communication, since the shared memory is not available in the file system anymore.

[owny990312]

@owny990312 yes, deleting /dev/shm would lead to the problem you are experiencing.是的，删除 /dev/shm 会导致你遇到的问题。

At least with Linux, deleting a shared memory does not mean that it's fully gone. It's just not anymore accessible via the file system but Linux keeps the memory available as long as there are open file descriptors.至少对于 Linux 来说，删除共享内存并不意味着它完全消失了。它只是不再可以通过文件系统访问，但只要还有打开的文件描述符，Linux 会继续保留这部分内存。 This is the case, since RouDi as well as the running app still have the file descriptor to keep the shared memory alive.这是情况，因为 RouDi 以及运行中的应用仍然拥有文件描述符以保持共享内存的存活。 So, those who are already running will keep running but no new is able to participate in the communication, since the shared memory is not available in the file system anymore.所以，已经在运行的将继续运行，但无法有新的参与者加入通信，因为共享内存不再存在于文件系统中了。

Thanks for your reply!

[elBoberido]

You're welcome. I guess the issue can be closed?