ROS2 foxy FastDDS subscriber cann't receive topic when run for a while (It was normal at first)

[CatRoad]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

receive topic 10hz normal

Current behavior

1. cannot recveive topic

• this topic was normal at first
• but cannot recv when run for a while

2. node process (pid=4702) cpu high 160%
this picture is thread CPU load

3. dds thread try to open shm file no exist: /dev/shm/fastrtps_c8bb2f8d76e467ef
sudo strace -p 4702 -f

4. gdb attach process， thread was stay in some function like: futex_wait_cancelable() and futex_abstimed_wait_cancelable()
watch the thread backtrace (whitch thread was 3rd most cpu load)

5.watch /proc/4702/fd, this process no use /dev/shm/fastrtps_c8bb2f8d76e467ef
ls -l /proc/4702/fd*

Steps to reproduce

three are 2# step in my test case：
step 1： run all ros node
step 2： kill all ros node

my killall script like this：
sudo killall -s 9 v4l2_camera_node
sudo killall -s 9 ros2
sudo killall -s 9 _ros2_daemon
... ...

---

i will run all -> kill all -> run all -> kill all ... ... loop ... ...

---

This is an occasional problem,
error maybe happen randomly.

Fast DDS version/commit

v2.1.4

Platform/Architecture

Ubuntu Focal 20.04 arm64

Transport layer

Shared Memory Transport (SHM)

Additional context

ROS2 Foxy

XML configuration file

no XML, Maybe default

Relevant log output

no DDS Log.
i would like to know : How to open FastDDS Log in ROS2 Foxy

Network traffic capture

No response

[CatRoad]

when bug happen, cannot see subcriber when use rosw topic info

[Mario-DL]

Hi @CatRoad,

Thanks for the detailed report and thanks for using Fast DDS.
The 2.1.x branch for ROS 2 Foxy reached its EOL last year and its not actively maintained anymore.

Based on what you described, you are sending a SIGKILL signal to stop the processes. My initial hard guess would be that things (including memory segments) may not be cleaning up properly since that signal in particular is not correctly handled upwards in the ROS stack. Check if killing the processes with -s 2 mitigates the issue. Also, make sure that you wait for the process to die (combining kill, trap and wait in Linux). Also, please check if the issue can be reproduced with a newer distro.

I am feeling free to move this issue to the proper forum since the version is not currently maintained.