Chapter 2. API Reference
Crashes in Comprehensive Mode
in Comprehensive mode, this indicates it has read uninitialized memory. The application should be changed to either
use calloc() (which zeroes memory), or initialize the memory before using it. The value 0xCECECECE may also be
seen in stack-allocated automatic variables, because in IDF most task stacks are originally allocated from the heap
and in C stack memory is uninitialized by default.
If an application crashes and the exception register dump indicates that some addresses or values were 0xFEFEFEFE,
this indicates it is reading heap memory after it has been freed (a "use after free bug".) The application should be
changed to not access heap memory after it has been freed.
If a call to malloc() or realloc() causes a crash because it expected to find the pattern 0xFEFEFEFE in free memory
and a different pattern was found, then this indicates the app has a use-after-free bug where it is writing to memory
which has already been freed.
Manual Heap Checks in Comprehensive Mode
rors relating to 0xFEFEFEFE, 0xABBA1234 or 0xBAAD5678. In each case the checker is expecting to find a given
pattern, and will error out if this is not found:
• For free heap blocks, the checker expects to find all bytes set to 0xFE. Any other values indicate a use-after-free
bug where free memory has been incorrectly overwritten.
• For allocated heap blocks, the behaviour is the same as for Light Impact mode. The canary bytes 0xABBA1234
and 0xBAAD5678 are checked at the head and tail of each allocated buffer, and any variation indicates a buffer
overrun/underrun.
Heap Task Tracking
Heap Task Tracking can be used to get per task info for heap memory allocation. Application has to specify the heap
capabilities for which the heap allocation is to be tracked.
Example code is provided in
Heap Tracing
Heap Tracing allows tracing of code which allocates/frees memory. Two tracing modes are supported:
• Standalone. In this mode trace data are kept on-board, so the size of gathered information is limited by the
buffer assigned for that purposes. Analysis is done by the on-board code. There are a couple of APIs available
for accessing and dumping collected info.
• Host-based. This mode does not have the limitation of the standalone mode, because trace data are sent to the
host over JTAG connection using app_trace library. Later on they can be analysed using special tools.
Heap tracing can perform two functions:
• Leak checking: find memory which is allocated and never freed.
• Heap use analysis: show all functions that are allocating/freeing memory while the trace is running.
How To Diagnose Memory Leaks
program is leaking memory. Use the xPortGetFreeHeapSize(), heap_caps_get_free_size(), or
related functions
to track memory use over the life of the application. Try to narrow the leak down to a single function
or sequence of functions where free memory always decreases and never recovers.
Standalone Mode
Once you've identified the code which you think is leaking:
• In the project configuration menu, navigate to Component settings -> Heap Memory Debugging
-> Heap tracing and select Standalone option (see CONFIG_HEAP_TRACING_DEST).
• Call the function
heap_trace_init_standalone()
can be used to record the memory trace.
Espressif Systems
If an application crashes reading/writing an address related to 0xCECECECE
Calls to
system/heap_task_tracking
If you suspect a memory leak, the first step is to figure out which part of the
986
Submit Document Feedback
heap_caps_check_integrity()
early in the program, to register a buffer which
may print er-
Release v4.4
Need help?
Do you have a question about the ESP32-S2 and is the answer not in the manual?