'eprosima::fastcdr::exception::NotEnoughMemoryException' what(): Not enough memory in the buffer stream error #266

Activity

1. inaki-debug commented on Apr 3, 2026

   

   inaki-debug

   on Apr 3, 2026

   More actions

   Hello! We just ran into this exact same issue today and managed to solve it. The root cause is a serialization format incompatibility between ROS 2 Humble and ROS 2 Jazzy when communicating over the same network.

   Here are the answers to your questions based on our hardware tests today:

   The Root Cause
   The NotEnoughMemoryException happens because Humble and Jazzy use different serialization protocols under the hood. Humble uses Fast-DDS with CDR v1, while Jazzy uses CDR v2.
   When your micro-ros-agent (running on Humble) receives a payload published by a Jazzy machine over the network, it tries to decode it using the older format. Because the formats don't match, the agent reads "garbage" data, misinterprets the payload size as something massive, tries to allocate memory it doesn't have, and immediately crashes.

   Answering your specific questions:

   Can that error occur simply because devices with different ROS2 versions are connected to the same network? / Can the error occur when entering ROS2 commands?

   Yes. If you run a Jazzy node locally, or use CLI commands like ros2 topic list or ros2 topic pub from the Jazzy machine, it sends DDS traffic formatted in CDR v2. The Humble agent catches this incompatible traffic and crashes.

   Why does it work / not work via SSH?

   There is a very important distinction here:

   • If you SSH from your Jazzy PC into the Humble PC, and run ROS 2 commands in that SSH terminal, it will work. This is because the commands are actually executing on the Humble machine, using Humble's native CDR v1 serialization.}
   • If you run ROS 2 commands locally on your Jazzy PC terminal, it sends the incompatible Jazzy data over the network, crashing the agent.

   The "Ghost Topic" Problem
   We also noticed that simply killing (Ctrl+C) the Jazzy node or stopping the local terminal doesn't immediately fix it. The topics somehow seemed to stay "alive" or cached on the network (it might be related to DDS discovery timeouts or the ROS 2 daemon, though we didn't test the exact mechanism). As long as those ghost topics were floating around, the agent kept crashing on startup.

   How we fixed it:

   To completely clear the error and get the agent running again, we had to do a hard reset:

   • Stop the Jazzy traffic: We completely turned off the Ubuntu 24.04 (Jazzy) machine to ensure zero incompatible DDS traffic was on the network.
   • Clean the MCU: We completely wiped the flash memory of our microcontroller to remove any corrupted buffers.
   • Reflash: We reflashed the micro-ROS firmware onto the MCU.
   • Restart the Agent: Ran the micro-ros-agent again on the Humble machine, and it worked flawlessly.

   Long-term prevention:
   If you need both the Jazzy and Humble computers on the same network but don't want the Jazzy machine to crash your agent, you must isolate them. Set a different ROS_DOMAIN_ID on the Jazzy machine (e.g., export ROS_DOMAIN_ID=5).