Move_group exits with segmentation fault when receiving a SIGINT

[JorgePH]

Description

I am receiving a segmentation fault when trying to close move_group node (with Ctrl+C or sending SIGINT).

ROS Distro

Jazzy

OS and version

Ubuntu 24.04.1 LTS

Source or binary build?

Binary

If binary, which release version?

2.12.1-1noble.20241228.033527

If source, which branch?

No response

Which RMW are you using?

CycloneDDS

Steps to Reproduce

Launch ur sim moveit demo (or any other package containing move_group):

ros2 launch ur_simulation_gz ur_sim_moveit.launch.py 

Close it with Ctrl+C

Expected behavior

All process should close with exit code -2.

Actual behavior

Move_group node returns a exit code -11, and prints a Segmentation fault error:
The complete error is:

[move_group-8] Stack trace (most recent call last):
[move_group-8] #6    Object "", at 0xffffffffffffffff, in 
[move_group-8] #5    Object "/opt/ros/jazzy/lib/moveit_ros_move_group/move_group", at 0x555b359e8a44, in _start
[move_group-8] #4    Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x7fba90c7d28a, in __libc_start_main
[move_group-8] #3    Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x7fba90c7d1c9, in 
[move_group-8] #2    Object "/opt/ros/jazzy/lib/moveit_ros_move_group/move_group", at 0x555b359e7517, in main
[move_group-8] #1    Object "/opt/ros/jazzy/lib/librclcpp.so", at 0x7fba912546b9, in rclcpp::Executor::~Executor()
[move_group-8] #0    Object "/opt/ros/jazzy/lib/librclcpp.so", at 0x7fba9124d9ce, in 
[move_group-8] Segmentation fault (Address not mapped to object [0x7fba50f35170])

Backtrace or Console output

https://gist.github.com/JorgePH/03bff938f42c78cd6256a0b379619db1

[JorgePH]

This is problematic specially for all test checking exit codes, because move_group makes them fail.

[github-actions]

This issue is being labeled as stale because it has been open 45 days with no activity. It will be automatically closed after another 45 days without follow-ups.

[CihatAltiparmak]

Hello, I can deal with this issue. AFAIK, If I am not wrong, I sorted out this in somewhere by resetting some interface/node instances here (please don't take into account the comments which is badly written). It seems to me that the issue can be related to the order of destroying instances. will try to take a look this weekend.