NotEnoughMemoryException crash at node init when RMW_FASTRTPS_USE_QOS_FROM_XML=1 with data_sharing AUTOMATIC (Humble / FastDDS 2.6.x)

[jameszhangpr]

Description

When using RMW_FASTRTPS_USE_QOS_FROM_XML=1 with a FastDDS XML profile that enables data_sharing: AUTOMATIC as the default (such as the one shipped with ros2/demos for the talker_loaned_message demo), the node crashes immediately at startup with:

eprosima::fastcdr::exception::NotEnoughMemoryException: Not enough memory in the buffer stream

The crash occurs before any user-defined topic is published — it happens during rcl_node_init when the internal ros_discovery_info publisher (which carries variable-length node-name strings) tries to serialize a ParticipantEntitiesInfo message.

Reproduction steps

# zero-copy.xml (minimal reproduction — same as ros2/demos/zero-copy.xml)
cat > /tmp/zero-copy.xml << 'EOF'
<?xml version="1.0" encoding="UTF-8" ?>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
  <publisher profile_name="default publisher profile" is_default_profile="true">
    <qos><data_sharing><kind>AUTOMATIC</kind></data_sharing></qos>
  </publisher>
  <subscriber profile_name="default subscription profile" is_default_profile="true">
    <qos><data_sharing><kind>AUTOMATIC</kind></data_sharing></qos>
  </subscriber>
</profiles>
EOF

FASTRTPS_DEFAULT_PROFILES_FILE=/tmp/zero-copy.xml \
  RMW_FASTRTPS_USE_QOS_FROM_XML=1 \
  RMW_IMPLEMENTATION=rmw_fastrtps_cpp \
  ros2 run demo_nodes_cpp talker_loaned_message

GDB backtrace (excerpt)

#0  raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  abort () at ./stdlib/abort.c:79
#2  eprosima::fastcdr::exception::NotEnoughMemoryException::raise() const
#3  eprosima::fastcdr::FastBuffer::resize(unsigned long)
#4  eprosima::fastcdr::FastCdr::serializeArray(char const*, unsigned long)
#5  eprosima::fastcdr::FastCdr::serialize<std::__cxx11::basic_string<...>>
...
#N  rmw_fastrtps_shared_cpp::__rmw_create_node(...)

The crash is inside __rmw_create_node, triggered by the first publish to ros_discovery_info.

Root cause

In rmw_fastrtps_cpp/src/publisher.cpp (Humble, rmw_fastrtps_cpp ≤ 6.2.7), when leave_middleware_default_qos = true (i.e. RMW_FASTRTPS_USE_QOS_FROM_XML=1), the following block is skipped:

    writer_qos.endpoint().history_memory_policy =
        PREALLOCATED_WITH_REALLOC_MEMORY_MODE;   // ← skipped
    writer_qos.data_sharing().off();              // ← skipped
}

On Humble / FastDDS 2.6.x, RTPSEndpointQos defaults history_memory_policy to PREALLOCATED_MEMORY_MODE (fixed-size, no reallocation). When the XML profile enables data_sharing: AUTOMATIC, the data_sharing().off() call is also skipped, so FastDDS attempts data-sharing on the internal ros_discovery_info publisher.

The internal topic carries strings (node names), so the fixed-size CDR buffer overflows → NotEnoughMemoryException.

Why Rolling is unaffected

Confirmed by testing: the same XML and command on Rolling (rmw_fastrtps_cpp 8.2.0 / FastDDS 2.13.2) works without any crash.

Affected versions

Component	Humble (broken)	Rolling (works)
ros-*-rmw-fastrtps-cpp	6.2.7	8.2.0
ros-*-fastrtps (FastDDS)	2.6.10	2.13.2
ros-*-fastcdr	1.0.24	1.1.0

Proposed fix

Option A (preferred): Unconditionally set PREALLOCATED_WITH_REALLOC_MEMORY_MODE in publisher.cpp, regardless of leave_middleware_default_qos. This prevents user XML from accidentally leaving the internal publisher in an unsafe state.

Option B (workaround for users): Document (and update ros2/demos/zero-copy.xml) that when RMW_FASTRTPS_USE_QOS_FROM_XML=1 is used on Humble, the XML must explicitly include:

<publisher profile_name="default publisher profile" is_default_profile="true">
  <historyMemoryPolicy>PREALLOCATED_WITH_REALLOC</historyMemoryPolicy>
  <qos><data_sharing><kind>OFF</kind></data_sharing></qos>
</publisher>

…and enable data_sharing: AUTOMATIC only for known POD/fixed-size topics via topic-specific profiles.

The ros2/demos repo has already applied Workaround B to zero-copy.xml as an immediate fix.

[MiguelCompany]

This is already documented here. See the note after the table