Hi Hartmut. Thanks for your response. I needed some time to check some code fragments and trying to systematically reduce the program to catch the bug. As I understand, lwIP does use zero copy by default; but some dev on the ESP32 forum told me, that the send()
function will not return before all bytes are sent out. So calling free()
after send()
has returned should be safe.
I studied the link you posted. But to be honest, I am currently just too rookie to understand the background and idea of the purpose of newlib and malloc hooks; but I will definitely read more about it (although there’s a newlib configuration item in the ESP32 sdkconfig which is enabled for my program).
However, I maybe “solved” the heap corruption issue by using a fixed-size array
instead of the flexible array
for the payload
field like so:
typedef struct mb32_packet_t {
uint16_t preamble;
uint8_t system_id;
uint8_t message_id;
uint8_t reserved;
uint16_t checksum;
uint32_t pay_len;
uint8_t payload[512];
} __attribute__((packed)) mb32_packet_t;
I didn’t change anything on my malloc()
and free()
constellation and I am still passing pointers to the queue. Now the program runs very stable, sending hundreds of sensor values per second from different tasks.
Can you imagine that this issue was related to the flexible array construct used together with the FreeRTOS queues?