Espressif ESP32-S2 Programming Manual page 995

Chapter 2. API Reference
Assertions The heap implementation (multi_heap.c, etc.) includes a lot of assertions which will fail if the
heap memory is corrupted. To detect heap corruption most effectively, ensure that assertions are enabled in the project
configuration menu under Compiler options -> CONFIG_COMPILER_OPTIMIZATION_ASSERTION_LEVEL.
If a heap integrity assertion fails, a line will be printed like CORRUPT HEAP: multi_heap.c:225 detected
at 0x3ffbb71c. The memory address which is printed is the address of the heap structure which has corrupt
content.
It's also possible to manually check heap integrity by calling
related functions. This function checks all of requested heap memory for integrity, and can be used even if assertions
are disabled. If the integrity check prints an error, it will also contain the address(es) of corrupt heap structures.
Memory Allocation Failed Hook
to register a callback that will be invoked every time a allocation operation fails.
Additionaly user can enable a generation of a system abort if allocation operation fails by following the
steps below: - In the project configuration menu, navigate to Component
ory Debugging and select Abort
FIG_HEAP_ABORT_WHEN_ALLOCATION_FAILS).
The example below show how to register a allocation failure callback:
#include "esp_heap_caps.h"
void heap_caps_alloc_failed_hook(size_t requested_size, uint32_t caps, const
*function_name)
→
{
printf("%s was called but failed to allocate
",function_name, requested_size, caps);
→
}
void app_main()
{
...
esp_err_t error
failed_hook);
→
...
void *ptr = heap_caps_malloc(allocation_size, MALLOC_CAP_DEFAULT);
...
}
Finding Heap Corruption
area of memory can be corrupted from a totally different place. Some tips:
• A crash with a CORRUPT HEAP: message will usually include a stack trace, but this stack trace is rarely
useful. The crash is the symptom of memory corruption when the system realises the heap is corrupt, but
usually the corruption happened elsewhere and earlier in time.
• Increasing the Heap memory debugging
you a more accurate message with the first corrupt memory address.
• Adding regular
heap_caps_check_integrity_addr()
that the corruption happened. You can move these checks around to "close in on"the section of code that
corrupted the heap.
• Based on the memory address which is being corrupted, you can use
this address and have the CPU halt when it is written to.
• If you don't have JTAG, but you do know roughly when the corruption happens, then you can set a watch-
point in software just beforehand via esp_cpu_set_watchpoint(). A fatal exception will occur
when the watchpoint triggers. For example esp_cpu_set_watchpoint(0, (void *)addr, 4,
ESP_WATCHPOINT_STORE. Note that watchpoints are per-CPU and are set on the current running CPU
only, so if you don't know which CPU is corrupting memory then you will need to call this function on both
CPUs.
Espressif Systems
Users can use heap_caps_register_failed_alloc_callback()
if
= heap_caps_register_failed_alloc_callback(heap_caps_alloc_
Memory corruption can be one of the hardest classes of bugs to find and fix, as one
Configuration
calls to
Submit Document Feedback
heap_caps_check_integrity_all()
memory allocation
%d bytes with
level to"Light impact"or"Comprehensive"can give
heap_caps_check_integrity_all()
in your code will help you pin down the exact time
JTAG debugging
984
config -> Heap Mem-
fails option (see CON-
char␣
0x%X capabilities. \n
to set a watchpoint on
Release v4.4
or
or