SDK 5.4 assert failed: block_locate_free tlsf_control_functions.h:618 (block_size(block) >= *size) (IDFGH-14384)

[filzek]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.4-1-g6b7b8ea3d2

Espressif SoC revision.

esp32 wrover

Operating System used.

Windows

How did you build your project?

Command line with Make

If you are using Windows, please specify command line type.

None

Development Kit.

esp32 wrover

Power Supply used.

External 5V

What is the expected behavior?

do not crash

What is the actual behavior?

crashing at:
assert failed: block_locate_free tlsf_control_functions.h:618 (block_size(block) >= *size)

Backtrace: 0x40082418:0x3ffdb5d0 0x40098efd:0x3ffdb5f0 0x4009cf2d:0x3ffdb610 0x4009c0b6:0x3ffdb740 0x4009bb03:0x3ffdb760 0x40082ebf:0x3ffdb780 0x40082ee5:0x3ffdb7b0 0x40082b83:0x3ffdb7d0 0x40090195:0x3ffdb830 0x40204171:0x3ffdb850 0x4020763c:0x3ffdb880 0x40205ae2:0x3ffdb8b0 0x40207ddd:0x3ffdb900 0x40207eab:0x3ffdb950 0x402021a2:0x3ffdb990
--- 0x40082418: panic_abort at C:/Espressif/frameworks/esp-idf-v5.4/components/esp_system/panic.c:454
0x40098efd: esp_system_abort at C:/Espressif/frameworks/esp-idf-v5.4/components/esp_system/port/esp_system_chip.c:92
0x4009cf2d: __assert_func at C:/Espressif/frameworks/esp-idf-v5.4/components/newlib/assert.c:80
0x4009c0b6: block_locate_free at C:/Espressif/frameworks/esp-idf-v5.4/components/heap/tlsf/tlsf_control_functions.h:618 (discriminator 1)
(inlined by) tlsf_malloc at C:/Espressif/frameworks/esp-idf-v5.4/components/heap/tlsf/tlsf.c:443 (discriminator 1)
0x4009bb03: multi_heap_malloc_impl at C:/Espressif/frameworks/esp-idf-v5.4/components/heap/multi_heap.c:209
0x40082ebf: aligned_or_unaligned_alloc at C:/Espressif/frameworks/esp-idf-v5.4/components/heap/heap_caps_base.c:77
(inlined by) heap_caps_aligned_alloc_base at C:/Espressif/frameworks/esp-idf-v5.4/components/heap/heap_caps_base.c:150
0x40082ee5: heap_caps_malloc_base at C:/Espressif/frameworks/esp-idf-v5.4/components/heap/heap_caps_base.c:170
0x40082b83: heap_caps_malloc_prefer at C:/Espressif/frameworks/esp-idf-v5.4/components/heap/heap_caps.c:180
0x40090195: wifi_malloc at C:/Espressif/frameworks/esp-idf-v5.4/components/esp_wifi/esp32/esp_adapter.c:80
0x40204171: esf_buf_alloc_dynamic at ??:?
0x4020763c: esf_buf_alloc at ??:?
0x40205ae2: wDev_IndicateAmpdu at ??:?
0x40207ddd: wDev_ProcessRxSucData at ??:?
0x40207eab: wdevProcessRxSucDataAll at ??:?
0x402021a2: ppTask at ??:?

Steps to reproduce.

heavy isr acting in gpio and sending http post

Debug Logs.

assert failed: block_locate_free tlsf_control_functions.h:618 (block_size(block) >= *size)

More Information.

No response

[SoucheSouche]

Hi @filzek,
this looks like the heap memory got corrupted and this corruption went undetected until an allocation caused the memory allocator to stumble across corrupted metadata and crashed.

You can try to pinpoint where the corruption happened by enabling comprehensive poisoning and calling heap_caps_check_integrity_all at several places in your code until you find the block of code that introduced the corruption.

See https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/heap_debug.html#finding-heap-corruption

[filzek]

doing all checks, to find where it is caused,

[AxelLin]

@SoucheSouche

A question regarding Memory Allocation Failed Hook: https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/heap_debug.html#memory-allocation-failed-hook
The functiona_name of heap_caps_alloc_failed_hook() is not helpful,
because it's just shows malloc or calloc.
Is it possible to show the function that calls the malloc/calloc?

[SoucheSouche]

@SoucheSouche

A question regarding Memory Allocation Failed Hook: https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/heap_debug.html#memory-allocation-failed-hook The functiona_name of heap_caps_alloc_failed_hook() is not helpful, because it's just shows malloc or calloc. Is it possible to show the function that calls the malloc/calloc?

@AxelLin,
the hook is called from all malloc, realloc and calloc set of functions from the esp_heap_caps.h API. It is not possible to provide the whole backtrace through this hook.

In the future, I would kindly ask you to create a ticket of your own instead of posting your questions on existing tickets. It is not because this ticket is related to the heap component that you should feel confident in posting any question that also relates to the heap component.

It is not the first time that I encounter a comment unrelated to the topic being discussed in the ticket coming from you (#13588 (comment)).

If you open your own tickets, you will get faster answer on our side without disrupting the conversation happening on other tickets.

[SoucheSouche]

doing all checks, to find where it is caused,

Hi @filzek,
Any success in finding the source of the corruption yet ?

[AxelLin]

It is not the first time that I encounter a comment unrelated to the topic being discussed in the ticket coming from you (#13588 (comment)).

I will avoid doing that, my apology.
But the reason of #13588 (comment) is
because YOU STOP RESPONSE in original thread espressif/tlsf#2 (comment) for several months.
I tried to get you attention when I notice you response on above thread (and from my knowledge it's related topic).

[filzek]

doing all checks, to find where it is caused,

Hi @filzek, Any success in finding the source of the corruption yet ?

@AxelLin, we have created a wrapper for all allocation functions (malloc, calloc, and realloc), indexing each variable, address, and size. We also free the memory and set the pointer to NULL upon deletion.

@SoucheSouche, we plan to release this as an ESP-IDF component, making it much easier to detect double frees and memory leaks.

We’re also developing wrappers for bzero and memset, as these can lead to memory corruption if the specified size is larger than the actual variable or pointer.

However, we’re not certain when this will be ready to use as a component.

If any of you would like to use our existing memory allocation control system, just let me know and I’ll send it over.

[filzek]

You can get it at my github for now:
https://github.com/filzek/Esp-IDF-MemoryAllocationControl/tree/main

[SoucheSouche]

@filzek, I had a brief look at your MemoryAllocationControl repo. It is nice to see that you are trying to build on top of the existing API to improve it.

did you know that the heap component already offers the possibility to get functions called on all allocations, all frees and all allocation failures or that it provides a way to trace calls to allocation and free functions.

• alloc failure hook
• heap tracing.

To come back to your initial memory corruption issue, you can find pointers on how to debug the heap memory in the Heap Memory Debugging section of EPS-IDF documentation.

I cannot heap you further with finding out where the memory corruption occurs in your application so I suggest closing this ticket.

[filzek]

I will close the issue, the allocation is not the problem or the free, as I have moved all kind of alloc to the traceable. Now I am checking all bzero, memset, memcpy and others chars manipulations