CORRUPTED external memory, using SPIRAM

[JacksonUtsch]

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

Run allocating buffer without crashing.

Actual behavior (suspected bug)

Before 10 minutes of running I usually get a crash due to corrupted memory.

Error logs or terminal output

Guru Meditation Error: Core  0 panic'ed (Unhandled debug exception). 
Debug exception reason: BREAK instr 
Core  0 register dump:
PC      : 0x3c1cf690  PS      : 0x00000018  A0      : 0x00000100  A1      : 0x82007e5a  
A2      : 0x3fcd18c0  A3      : 0x00000100  A4      : 0x00000040  A5      : 0x0000007f  
A6      : 0x3fca80e0  A7      : 0x3c232228  A8      : 0x3c23022c  A9      : 0x820078c1  
0x3fca80e0 - pxReadyTasksLists
    at ??:??
0x3c232228 - os_msys_init_1_data
    at ??:??
0x3c23022c - ble_hs_hci_os_event_buf
    at ??:??
A10     : 0x3fcd18e0  A11     : 0x3fcd1a00  A12     : 0x00000000  A13     : 0x03ca121c  
A14     : 0x3fca121c  A15     : 0x01ffffff  SAR     : 0x3c2329fc  EXCCAUSE: 0x00000001  
0x3fca121c - mux
    at ??:??
0x3c2329fc - pool_cmd_buf
    at ??:??
EXCVADDR: 0xffffffec  LBEG    : 0x3fcd1980  LEND    : 0xffffff00  LCOUNT  : 0x00000000  


Backtrace: 0x3c1cf68d:0x82007e5a |<-CORRUPTED

Here's another example

Guru Meditation Error: Core  0 panic'ed (Unhandled debug exception). 
Debug exception reason: BREAK instr 
Core  0 register dump:
PC      : 0x3fceff5c  PS      : 0x3fceff68  A0      : 0x00000100  A1      : 0x82007e5a  
A2      : 0x3fcd2840  A3      : 0x00000100  A4      : 0x00000040  A5      : 0x0000007f  
A6      : 0x420f03b8  A7      : 0x3fcc1ef8  A8      : 0x420eff1c  A9      : 0x820078c1  
0x420f03b8 - semphr_take_wrapper
    at esp-idf/v5.5.1/components/bt/controller/esp32c3/bt.c:902
0x420eff1c - coex_schm_register_btdm_callback_wrapper
    at esp-idf/v5.5.1/components/bt/controller/esp32c3/bt.c:2291
A10     : 0x3fcd2860  A11     : 0x3fcd2980  A12     : 0x00000000  A13     : 0x03ca181c  
A14     : 0x3fca181c  A15     : 0x01ffffff  SAR     : 0x3fca3ca0  EXCCAUSE: 0x00000001  
0x3fca181c - mux
    at ??:??
0x3fca3ca0 - port_IntStack
    at ??:??
EXCVADDR: 0xffffffec  LBEG    : 0x3fcd2900  LEND    : 0x3c26a684  LCOUNT  : 0x00000000  


Backtrace: 0x3fceff59:0x82007e5a |<-CORRUPTED

Steps to reproduce the behavior

Using rust bindings but is the same

let mut desc = core::mem::MaybeUninit::uninit();
let rc = unsafe {
    esp_idf_svc::sys::ble_gap_conn_find(
        connection.conn_handle,
        desc.as_mut_ptr()
    )
};
if rc != 0 {
    // not connected
    warn!("not connected ble so skipping");
} else {
    // connection exists
    let om = unsafe { esp_idf_svc::sys::ble_hs_mbuf_from_flat(packet.as_ptr() as *const std::ffi::c_void, packet.len() as u16) };
    if om.is_null() {
        eprintln!("NULL MBUF");
    } else {
        unsafe {
            let rc = esp_idf_svc::sys::ble_gatts_notify_custom(connection.conn_handle, char.handle, om);
            if rc != 0 {
                eprintln!("Failed to notify custom");
            }
        };
    }
}

Project release version

Using esp-idf v5.5.1

System architecture

ARM 64-bit (Apple M1/M2, Raspberry Pi 4/5)

Operating system

MacOS

Operating system version

macOS 15.0

Shell

Bash

Additional context

Using the esp32-s3

I have enabled

CONFIG_BT_NIMBLE_MEM_ALLOC_MODE_EXTERNAL=y
CONFIG_BT_NIMBLE_MSYS_BUF_FROM_HEAP=y

In order to use SPIRAM

I am sending a lot of data frequently but I still should be able to avoid the crash. I should just get null buffers if that is the case. Though, I do get null buffers NULL MBUF and also Failed to notify custom printed. I just can't have a crash occur but failing with these is fine.