Guru Meditation Error (LoadProhibited) when sending WebSocket data after VAD_START (ESP-IDF v5.5.1) (AEGHB-1377)

[liujkek22]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate
• Read the documentation to confirm the issue is not addressed there and your configuration is set correctly
• Tested with the latest version to ensure the issue hasn't been fixed

How often does this bug occurs?

often

Expected behavior

• The system should not crash when calling esp_websocket_client_send_text() with invalid or unexpected parameters.
• If the input buffer pointer is NULL, out of scope, or otherwise invalid, the API should return an error instead of triggering a system panic.
• WebSocket + TLS send operations should fail gracefully and provide clear error codes for incorrect usage.

Actual behavior (suspected bug)

Environment

Project: esp-brookesia / products/speaker

ESP-IDF Version: v5.5.1

Target: ESP32-S3

Commit: 366db8b

Branch: master

Author of commit: Liu Zhongwei

Build type: Release

Transport: WebSocket over TLS (esp_websocket_client)

Description

After the audio processor reports VAD_START, the system crashes with a Guru Meditation Error (LoadProhibited) on Core 0.

The panic occurs during a WebSocket text send operation, inside the TLS layer (mbedTLS), and finally crashes in memcmp from ROM due to an invalid memory access.

This issue seems to be related to the data buffer passed to esp_websocket_client_send_text().

Panic Log (Excerpt)
AUDIO_PROCESSOR: VAD_START
Guru Meditation Error: Core 0 panic'ed (LoadProhibited)
EXCVADDR: 0x00000000

PC : 0x40056ece memcmp in ROM
...
Backtrace:
0x40056ecb: memcmp in ROM
0x42265f09: ssl_check_ctr_renegotiate
0x422673dd: mbedtls_ssl_write
0x42269cda: __wrap_mbedtls_ssl_write
0x4225f40f: esp_mbedtls_write
0x42319da6: esp_tls_conn_write
0x42260265: ssl_write
0x42319f19: esp_transport_write
0x42261029: _ws_write
0x4226113f: esp_transport_ws_send_raw
0x4216c814: esp_websocket_client_send_with_exact_opcode
0x4216d51d: esp_websocket_client_send_with_opcode
0x4216a6bc: coze_data_push_task
Analysis

The crash happens inside memcmp() with EXCVADDR = 0x00000000, indicating a NULL or invalid pointer dereference.

The call stack shows that the pointer originates from coze_data_push_task, during a call to esp_websocket_client_send_text().

This suggests that:

The buffer pointer passed to the WebSocket send API may be NULL, invalid, or already out of scope.

Or the buffer lifetime does not meet the asynchronous requirements of TLS/WebSocket transmission.

Or there may be concurrent access to the same WebSocket client from multiple tasks.

Expected Behavior

Calling esp_websocket_client_send_text() with valid parameters should not cause a system panic.

Invalid parameters should be safely rejected or return an error instead of crashing.

Questions

Does esp_websocket_client_send_text() require the data buffer to remain valid until the internal TLS transmission is fully completed?

Is the WebSocket client thread-safe, or must all send operations be serialized by the user?

Are there recommended best practices for buffer lifetime management when sending data over WebSocket + TLS in ESP-IDF?

Additional Notes

The issue is reproducible after VAD_START.

The project does not intentionally pass NULL buffers, but the data may be allocated on the task stack or via temporary objects.

Any guidance or confirmation would be appreciated. Thank you.

Error logs or terminal output

429. AUDIO_PROCESSOR: VAD_START
     Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled.

Core 0 register dump:
PC : 0x40056ece PS : 0x00060e30 A0 : 0x82265f0c A1 : 0x3c8c66c0
--- 0x40056ece: memcmp in ROM
A2 : 0x00000000 A3 : 0x3c889860 A4 : 0x00000008 A5 : 0x00060e23
A6 : 0x00000001 A7 : 0x3fcb2480 A8 : 0x00000002 A9 : 0x3c8c6680
A10 : 0x3c8c2774 A11 : 0x00001155 A12 : 0x00000404 A13 : 0x00060e23
A14 : 0xb33fffff A15 : 0x00000001 SAR : 0x00000018 EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000000 LBEG : 0x40056fc5 LEND : 0x40056fe7 LCOUNT : 0xffffffff
--- 0x40056fc5: memcpy in ROM
--- 0x40056fe7: memcpy in ROM

Backtrace: 0x40056ecb:0x3c8c66c0 0x42265f09:0x3c8c66e0 0x422673dd:0x3c8c6700 0x42269cda:0x3c8c6720 0x4225f40f:0x3c8c6740 0x42319da6:0x3c8c6760 0x42260265:0x3c8c6780 0x42319f19:0x3c8c67c0 0x42261029:0x3c8c67e0 0x4226113f:0x3c8c6810 0x4216c814:0x3c8c6830 0x4216d51d:0x3c8c6870 0x4216a6bc:0x3c8c6890
--- 0x40056ecb: memcmp in ROM
--- 0x42265f09: ssl_check_ctr_renegotiate at /home/x/Desktop/esp32/esp3255/esp-idf/components/mbedtls/mbedtls/library/ssl_msg.c:5693
--- 0x422673dd: mbedtls_ssl_write at /home/x/Desktop/esp32/esp3255/esp-idf/components/mbedtls/mbedtls/library/ssl_msg.c:6198
--- 0x42269cda: __wrap_mbedtls_ssl_write at /home/x/Desktop/esp32/esp3255/esp-idf/components/mbedtls/port/dynamic/esp_ssl_tls.c:336
--- 0x4225f40f: esp_mbedtls_write at /home/x/Desktop/esp32/esp3255/esp-idf/components/esp-tls/esp_tls_mbedtls.c:402
--- 0x42319da6: esp_tls_conn_write at /home/x/Desktop/esp32/esp3255/esp-idf/components/esp-tls/esp_tls.c:148
--- 0x42260265: ssl_write at /home/x/Desktop/esp32/esp3255/esp-idf/components/tcp_transport/transport_ssl.c:229
--- 0x42319f19: esp_transport_write at /home/x/Desktop/esp32/esp3255/esp-idf/components/tcp_transport/transport.c:148
--- 0x42261029: _ws_write at /home/x/Desktop/esp32/esp3255/esp-idf/components/tcp_transport/transport_ws.c:420
--- 0x4226113f: esp_transport_ws_send_raw at /home/x/Desktop/esp32/esp3255/esp-idf/components/tcp_transport/transport_ws.c:448
--- 0x4216c814: esp_websocket_client_send_with_exact_opcode at /home/x/Desktop/esp32/esp3255/project55/esp-brookesia/products/speaker/managed_components/espressif__esp_websocket_client/esp_websocket_client.c:650
--- 0x4216d51d: esp_websocket_client_send_with_opcode at /home/x/Desktop/esp32/esp3255/project55/esp-brookesia/products/speaker/managed_components/espressif__esp_websocket_client/esp_websocket_client.c:1353
--- (inlined by) esp_websocket_client_send_text at /home/x/Desktop/esp32/esp3255/project55/esp-brookesia/products/speaker/managed_components/espressif__esp_websocket_client/esp_websocket_client.c:1323
--- 0x4216a6bc: coze_data_push_task at esp_coze_chat.c.obj:?

ELF file SHA256: ef638fa56

Rebooting...
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0xb (SPI_FAST_FLASH_BOOT)
Saved PC:0x40382f34
--- 0x40382f34: esp_restart_noos at /home/x/Desktop/esp32/esp3255/esp-idf/components/esp_system/port/soc/esp32s3/system_internal.c:162
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce2820,len:0x1700
load:0x403c8700,len:0xe5c
--- 0x403c8700: _stext at ??:?
load:0x403cb700,len:0x31cc
entry 0x403c8940
--- 0x403c8940: call_start_cpu0 at /home/x/Desktop/esp32/esp3255/esp-idf/components/bootloader/subproject/main/bootloader_start.c:25
I (24) boot: ESP-IDF v5.5.1 2nd stage bootloader
I (24) boot: compil

Steps to reproduce the behavior

1. Flash the firmware built from commit 366db8b42a7609d7153362d0becd350126846750 using ESP-IDF v5.5.1.
2. Boot the device and establish a WebSocket (TLS) connection to the AI chat backend.
3. Start an AI chat session and begin streaming audio data from the microphone.
4. When voice activity is detected, the log prints AUDIO_PROCESSOR: VAD_START.
5. Shortly after VAD_START, the device attempts to send chat-related data via esp_websocket_client_send_text().
6. The system occasionally crashes with a Guru Meditation Error (LoadProhibited) on Core 0.

Project release version

commit：366db8b42a7609d7153362d0becd350126846750

System architecture

other (details in Additional context)

Operating system

Linux

Operating system version

ubuntu25.04

Shell

Bash

Additional context

No response

[Lzw655]

Hi @liujkek22,

I haven't been able to reproduce this issue. May I ask, is the probability of it occurring high? Have you made any modifications to the code?