ESP32 crashes when listening_message_reliably

Chưa có ai nhận issue này.

## ESP32 crashes when listening_message_reliably

- Hardware description: ESP32 serially linked to a nRF5340DK (using UART1 on pins 19/18 as TX/RX)
- RTOS: FreeRTOS
- Installation type: micro_ros_espidf_component, ESP IDF v4.4
- Version or commit hash: humble

#### Steps to reproduce the issue
My project consist on controlling a BT Mesh provisioner via ROS, and transmitting sensors data from the Mesh network to ROS.
The ESP32 serves as a message bridge between the provisioner and ROS.
For that I've got 4 threads running :
- the uROS thread (priority 5, stack 16000 bytes) with 2 subs and 2 pubs
- an "uart_phy" thread (priority 6, stack 4096 bytes) which job is to read data from UART1 and sends it to uart_mac_rx with a message queue
- 2 "uart_mac_rx" and "uart_mac_tx" threads (priority 6, stack 4096 bytes). uart_mac_rx gets data from uart_phy and publishes message to ROS. uart_mac_tx receives messages from the subscribers callbacks and transmits data to UART1

The nRF5340 scans for unprovisioned ("unconnected") mesh nodes, and sends the UUIDs to the ESP32 via serial.
So the ESP32 receives a 16 bytes UUID from UART, the uart_phy sends this UUID to uart_mac_rx through a message queue.
uart_mac_rx wakes up because something is in the queue, sees that it is an UUID, and publish it with my "unprov_pub".
The ROS message is the following :
ble2ros_interfaces/msg/Beacon.msg
```
# Represent an unprovisioned beacon from BT Mesh
uint8[16] uuid
```

#### Expected behavior
UUIDs are sent to ROS without error

#### Actual behavior
Sometimes, mostly when the ESP32 receives a lot of UUID's to transmit to ROS, i got the following error :
`assert failed: pbuf_free IDF/components/lwip/lwip/src/core/pbuf.c:757 (pbuf_free: p->ref > 0)`
OR
`assert failed: tlsf_free heap_tlsf.c:872 (!block_is_free(block) && "block already marked as free")`

but mostly the pbuf_free assert failed.
The most frequent stack backtrace is the following :
```
assert failed: pbuf_free IDF/components/lwip/lwip/src/core/pbuf.c:757 (pbuf_free: p->ref > 0)

Backtrace:0x40081ade:0x3ffd0a700x400891bd:0x3ffd0a90 0x4008fd5d:0x3ffd0ab0 0x400f3de7:0x3ffd0bd0 0x401057c1:0x3ffd0bf0 0x400f03ef:0x3ffd0c10 0x400f0ff2:0x3ffd0c50 0x400f1072:0x3ffd0cb0 0x400de19d:0x3ffd0cd0 0x400ddfad:0x3ffd0d00 0x400dd2fc:0x3ffd0d30 0x400dd488:0x3ffd0dd0 0x400e2836:0x3ffd0df0 0x400e0e4b:0x3ffd0e40 0x400da51d:0x3ffd0eb0 0x400da563:0x3ffd0ef0 0x400d6e6c:0x3ffd0f10 0x400d6e7e:0x3ffd0f30 0x4008c37d:0x3ffd0f50
0x40081ade: panic_abort at /home/samy/esp/esp-idf/components/esp_system/panic.c:402
0x400891bd: esp_system_abort at /home/samy/esp/esp-idf/components/esp_system/esp_system.c:128
0x4008fd5d: __assert_func at /home/samy/esp/esp-idf/components/newlib/assert.c:85
0x400f3de7: pbuf_free at /home/samy/esp/esp-idf/components/lwip/lwip/src/core/pbuf.c:757 (discriminator 1)
0x401057c1: netbuf_delete at /home/samy/esp/esp-idf/components/lwip/lwip/src/api/netbuf.c:85
0x400f03ef: lwip_recvfrom_udp_raw at /home/samy/esp/esp-idf/components/lwip/lwip/src/api/sockets.c:1250
0x400f0ff2: lwip_recvfrom at /home/samy/esp/esp-idf/components/lwip/lwip/src/api/sockets.c:1292 (discriminator 4)
0x400f1072: lwip_recv at /home/samy/esp/esp-idf/components/lwip/lwip/src/api/sockets.c:1337
0x400de19d: uxr_read_udp_data_platform at ??:?
0x400ddfad: recv_udp_msg at udp_transport.c:?
0x400dd2fc: listen_message_reliably at session.c:?
0x400dd488: uxr_run_session_until_data at ??:?
0x400e2836: rmw_wait at ??:?
0x400e0e4b: rcl_wait at ??:?
0x400da51d: rclc_executor_spin_some$part$5 at executor.c:?
0x400da563: rclc_executor_spin_some at ??:?
0x400d6e6c: spin_uros at /home/samy/work/ble2ros/firmware/uros_node/main/uros/uros.c:119 (discriminator 1)
0x400d6e7e: uros_task at /home/samy/work/ble2ros/firmware/uros_node/main/uros/uros.c:126
0x4008c37d: vPortTaskWrapper at /home/samy/esp/esp-idf/components/freertos/port/xtensa/port.c:131
```

#### Additional information
I also had other configuration with at most 4 pubs and 4 subs, and this problem can occur with any publisher.
I went back to 2 pubs and 2 subs to get back to the basic uROS config (also resetted the max pub/sub in colcon.meta)

I looked if the heap became corrupted at some point, but it was always clean.

When disabling asserts, it stills crash with Guru meditation error: Core 0 panic'ed

I tried lowering priorities, (12 for UART, 11 for uROS), switching priorities (4 for UART, 5 for uROS), still got the same problem.

Looked over the internet for solutions, looked in this repo's issues, found nothing...

Looked if I had memory leaks, but found none

Bắt đầu từ các điểm vào của backtrace uxr_read_udp_data_platform, recv_udp_msg và listen_message_reliably, sau đó tái hiện lỗi bằng thiết lập ESP-IDF 4.4 trong điều kiện lưu lượng UUID cao. So sánh các lỗi pbuf_free và tlsf_free trong khi kiểm tra cấu hình UART, task và publisher đã mô tả. Công việc được xem là hoàn tất khi nguyên nhân crash được cô lập và issue có fix hoặc workaround đã được xác minh.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.