rclc_support_init is corrupting FreeRTOS Heap

[DrMarkusKrug]

Issue template

• Hardware description: STM32L4
• RTOS: FreeRTOS
• Installation type: standard
• Version or commit hash: humble

Steps to reproduce the issue

I created a FreeRTOS heap with 16kByte and a 'Standard Task' with 12000 Bytes. Additionally I created 2 binary Semaphores.

Expected behavior

Semaphores stay as they are, completely independent of the micro ROS function cals

Actual behavior

in the function call rclc_support_init it seems that the FreeRTOS Heap gets corrupted and the semaphores get affected. Maybe other FreeRTOS elements as well

Additional information

[DrMarkusKrug]

[YuriiHordiienko1987]

Hello, Dear experts!
As @DrMarkusKrug described the problem, I've also stumbled with the similar one.
I use heap_4 in FreeRTOS with static heap (ucHeap) definition.

I defined custom allocators (identically to @DrMarkusKrug's example) for heap_4 according to many examples out of box, then wanted to initialize rcl as well, but it seems the program crashed at the last function call rcl_init_options_init, i.e. not at the rclc_support_init:

rcl_init_options_t init_options = rcl_get_zero_initialized_init_options();
RCCHECK(rcl_init_options_init(&init_options, allocator));

I see the issue was opened, but it really makes sense to investigate the problem further. I will do an effort from my side too.
CC: @pablogs9
Thanks!

UPD: detected issue comes from rmw_init_options_init function.

[DrMarkusKrug]

Hi,

I did not investigate the matter further after I got it working for me. As I recall, I changed the recommended memory allocation scheme significantly and used the FreeRTOS malloc wrappers.
If needed, I can look it up again and provide further guidance.
As far as I understood Pablo last year, the problem may not be in microros at all, but in ROS2 (which is partly used by microros). Probably because the architects of ROS2 were not aware of the actual memory limitations of a real-time operating system on a relatively small µC - or it was never a development goal to support small µC. So I don't know if the problem can be changed that easily.
I've written about this a few times before. In my opinion, the whole ROS1/2 architecture has been developed completely ignoring the reality of µC. Yes, ROS1/2 is an interesting concept with a large number of tools and possibilities. But it only works acceptably (if at all) on embedded systems in the class of an nvidia Jetson or raspberry Pi because it requires a lot of memory and CPU resources. In my opinion, however, this class of processors are no longer µCs, but already very powerful processor systems for which complex operating systems are available.

Best Regards
Markus