Node tries to open non-existing segment

[heinemichael]

Generated by Generative AI

No response

Operating System:

22.04.1-Ubuntu

ROS version or commit hash:

humble

RMW implementation (if applicable):

rmw_fastrtps_cpp

RMW Configuration (if applicable):

<?xml version="1.0" encoding="UTF-8" ?>
<dds>
    <profiles xmlns="http://www.eprosima.com">
        <publisher profile_name="default publisher profile" is_default_profile="true">
            <qos>
                <publishMode>
                    <kind>SYNCHRONOUS</kind>
                </publishMode>
                <data_sharing>
                    <kind>AUTOMATIC</kind>
                </data_sharing>
            </qos>
            <historyMemoryPolicy>PREALLOCATED_WITH_REALLOC</historyMemoryPolicy>
        </publisher>

        <!-- Default subscriber profile -->
        <subscriber profile_name="default subscriber profile" is_default_profile="true">
            <qos>
                <data_sharing>
                    <kind>AUTOMATIC</kind>
                </data_sharing>
            </qos>
            <historyMemoryPolicy>PREALLOCATED_WITH_REALLOC</historyMemoryPolicy>
        </subscriber>
    </profiles>
</dds>

Client library (if applicable):

No response

'ros2 doctor --report' output

No response

Steps to reproduce issue

1. Use shared memory as the transport layer
2. Stress the CPU cores for better reproduction (e.g. with stress)
3. Launch many ROS nodes at the same time

Expected behavior

All ROS nodes start up without errors

Actual behavior

In rare non-deterministic cases, a node fails during initialization by trying to opening a shared segment file, which does not exist:

[HISTORY_DATASHARING_LISTENER Error] Failed to open segment fast_datasharing_<specifier>: No such file or directory -> Function open_and_init_shared_segment_notification

Under /dev/shm, I can also not see this file.

Additional information

The nodes are not launched in a docker container.

Executing fastdds shm clean before launching the nodes does not help.

I'm not sure if the problematic node tries to initialize a service client/server. Could that be a problem with my configuration?

I also have full permissions on the /dev/shm folder.

sysctl -a | grep shmmax
=> kernel.shmmax = 18446744073692774399