-
Notifications
You must be signed in to change notification settings - Fork 7.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
assert failed: block_trim_free heap_ulsf.c:377 (block_is_free(block) && "block must be free") (IDFGH-6657) #8293
Comments
This was due to a nasty traceable heap poisoning case, closing. |
So I appear to still hit this bug. Which version of ESP-IDF has this been fixed in? I'm on ESP-IDF v4.4.3-347-g9ee3c8337d. I get exactly the same assertion. |
Hi all, From the arduino-esp32#7274 espressif/arduino-esp32#7274 (comment), This issue still occurs on ESP-IDF 4.4.4. Based on esp-idf v4.4.4 + esp32S3 + external spiram : Using the nimble client function, we have an interface in the BLE_GAP_EVENT_NOTIFY_RX event to process the received data, analyze and package the received data and push it into the queue, and then other threads will report the data in the queue to the cloud; This interface will report an error in malloc when Bluetooth data is reported frequently assert failed: block_trim_free heap_tlsf.c:371 (block_is_free(block) && "block must be free") However, this interface has never reported this error when the reporting frequency is low or the interface reads data from the serial port (instead of nimble). We also use malloc to test the allocation of internal ram and psram, and the same error occurs, and the malloc API will not be fully executed to the last return line; the error has already started to be reported directly inside the call to malloc() or heap_caps_malloc(). The detailed log is as follows:
|
首先添加了allocation failure callback相关接口,但是崩溃时并不会出现相关的错误打印
之后我启用了heap tracing,设置等级Comprehensive;Standalone Mode,设置其中buffer(1000)在我怀疑的函数接口内使用ESP_ERROR_CHECK( heap_trace_start(HEAP_TRACE_LEAKS) );&&ESP_ERROR_CHECK( heap_trace_stop() );在这一过程中除了有我接口里调用的malloc这两个
还会有下面的一次或多次下面几组的malloc
|
Environment
xtensa-esp32-elf-gcc --version
to find it):esp-2021r2-patch2-8.4.0
Problem Description
I got a assertion in malloc:
assert failed: block_trim_free heap_ulsf.c:377 (block_is_free(block) && "block must be free")
The backtrace:
I've seen issue #7746, but that fix seems to have something to do with DHCP, I think my issue is not related.
I think issue #8270 may be related.
Expected Behavior
malloc should not throw a assertion.
Steps to reproduce
I can't share my code here, but I'm able to provide more info when necessary.
The text was updated successfully, but these errors were encountered: